Historical actuals (time slice issue)

[MatthewPalicki]

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?

 

Thanks

[Deactivated User]

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

https://communities.ca.com/message/18051502#18051502

Regarding new slices see

https://communities.ca.com/message/241710824#241710824

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.

[Doug Kalkowski]

Mathew,

 

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.

 

-Doug

[Nick Darlington]

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.

 

-Doug

 

 

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

 

Thanks.

 

-Nick

 

* 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

 

Where:

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.

 

E.g.

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.

[MatthewPalicki]

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