View Only
  • 1.  Historical actuals (time slice issue)

    Posted Apr 08, 2015 10:01 PM

    I'm trying to get some historical data on timesheet actuals from 2014. I'm running into an issue which I know is due to time slicing, but I am not sure how to resolve.


    If I run a report such as "Investment Time and Estimate Review", and report on all time periods from 2014, the report returns data back as far as 01-April, but nothing prior to that.


    Similarly, if I attempt to use any portlets to show actuals posted in 2014 using a time-scaled value, whether set to quarters, years, or whatever, I get the dreaded "time periods do not exist".


    We've been fighting this since we first implemented Clarity. I know that you can create your own time slices buut that is discouraged by CA as it supposedly has a negative impact on performance. However we are tired of not being able to get the data we need.


    Can anyone point me to instructions on how to create my own time slices - or better yet, does anyone have any suggestions on how I may be able to see historical actuals on investments (equivalent to the Investment Time and Estimate Review report) for ALL of 2014?



  • 2.  Re: Historical actuals (time slice issue)

    Posted Apr 09, 2015 01:30 AM

    There is a whole series of Tuesday's tips on Time Slices starting from

    Regarding new slices see

    and the screenshot there, just press new in the Time Slices page to open that.


    There was a similar question a little while ago, but I simply can't find it searching these discussions (again). Maybe you can find it.

  • 3.  Re: Historical actuals (time slice issue)
    Best Answer

    Posted Apr 17, 2015 03:05 PM



    You can always adjust the "From Date" and number of periods for your timeslices.  So if your monthly actuals "From Date" is 4/1/14, just change it to be further in the past and update the number of periods accordingly.  Just remember that this is a rolling date, so if you change it to 1/1/14, next month it will roll forward to 2/1/14. So you'll need to set it back far enough to keep your reporting consistent (like 1-2 years in the past for monthly actuals).


    Also keep in mind that when you change this date, a full reslice occurs, so only do this when the system is not being heavily used, like on a Friday afterhours.


    As far as building your own timeslices, CA doesn't discourage creating custom time slices, you just have to be aware of the load you are putting on the system.  Nothing prevents you from creating an availability slice to the year 3000, but doing so would really hurt your system.  You just have to use them properly.



  • 4.  Re: Historical actuals (time slice issue)

    Posted Apr 17, 2015 03:55 PM

    DK_Winmill wrote:


    Nothing prevents you from creating an availability slice to the year 3000, but doing so would really hurt your system.  You just have to use them properly.





    There's a relation in most versions of Clarity between the amount of memory required on the bg and the length of your time slices; so the nature of your statements is true - doing so would really hurt the system (it would crash with an out of memory error) - so I would probably encourage keeping the number of periods down to 500 or less (1000 or less if 500 is really too few), no matter what size those periods are (days, weeks, months, etc.).


    There is a fix to the problem I mention above in 14.2 (against this defect: CLRT-73937 Configuring a time slice with a large number of periods can cause job scheduler service to crash in a loop with java.lang.OutOfMemoryError ), but earlier versions do not have it**.


    Alternatively to having a huge slice with too many periods, have it slice to the year 3000*, so long as it's starting from about 2997 or so






    * I think this will still probably have some issues in most environments, but I get that it's just 'for example'.

    ** Here also is the workaround I constructed for the defect, in case a reader/visitor finds it useful.  The numbers here are not absolutes, they were derived from some rudimentary profiling with a 64-bit JVM, so your mileage may vary in your own systems:


    For both On-Premise and OnDemand customers:

    - Decrease the number of periods to a value less than or equal to 1080 at least (this is 3 years of daily values), possibly even more.


    For On-Premise customers only, not OnDemand.

    - Increase the -Xmx of the bg service to be sufficient for the number of periods.


    If increasing the -Xmx value, consider the following as a starting guideline for what to set:


    ((number_of_periods_in_slice / 1000) * 500) + 500 + buffer



    number_of_periods = the largest number of periods set for a single slice request

    buffer = any additional memory needed to run other reports/jobs/processes


    If you're unsure what to set the buffer value to, take your current -Xmx value and subtract 512 from it.



    Current -Xmx is 1024m

    DAILYRESOURCEAVAILCURVE periods is set to 7200


    You would likely want to set your -Xmx value to this in order to have a chance of it completing comfortably in this configuration:


    ((7200 / 1000) * 500) + 500 + (1024 - 512)

    = -Xmx4612m


    Or even set it to -Xmx5120m to be safer in this example (this is 1024m * 5, or 5GB) since some of the memory set in the -Xmx parameter is also reserved for other purposes.


    Restart the bg service after making changes to the -Xmx parameter in the CSA > server properties > background > JVM Parameters field.

  • 5.  Re: Historical actuals (time slice issue)

    Posted Apr 20, 2015 08:03 AM

    Thanks - We were able to determine the time slice being used, and change the start date from 01-April to 01-January, and this allowed us to get the full year's data. Thanks for the help