TM1 Forum

I've got a feeder thus:
In 9.4 this is tripping over a bug caused by exceeding the depth of the rule evaluation stack, currently 1600.

The bank opening balance of day N is the closing balance of day N-1. The closing balance is a consolidation of the opening balance plus any movements, so using the closing balance to feed the opening balance is causing quite a bit of work to go on as there is a massive chain of feeders stretching right back to day 1.

My proposed solution is this: to change the feeder to be
['Opening Balance', 'Day 1'] => ['All days', 'Opening Balance'];

I.e. use one single value to feed thousands of lines. There are 3000+ (i.e. more than 1600) elements in this dimension.

So my questions is, am I correct in thinking that this won't be affected by the stack limitation of 1600 because each feeder is independent? And that instead of having a massive chain of feeders, I'm merely going to have one feeder occur 3000+ times?

Comments on alternative designs welcome too as I realise this isn't a "pure" way of doing the feeders.

Martin

Martin,

you may replace rules calculated data with materialized data with an TI process, at least for time periods in the past that are not subject to scenario changes any more. If your business process allows of course.

M.

I would agree with Marcus. Daily Stock (or cashflow, whatever) is quite a tricky area for TM1, because of the stack overflow issue. I recall Steve Rowe finding that the stack size had been shrunk round 8.somepointversion.

We hit this at a client last year. 64 bit, large cube calculating closing stock from opening (yesterday's closing), production and issues. The message log filled up with thousands of stack overflow messages. Most of the numbers in the cube were good, but there were some nasty little errors coming through - gave the client some discomfort. In this case, we didn't roll over years because there was an opening balance coming from Oracle - but we still got the overflows.

We addressed it in a pragmatic way by chopping the year into two. The closing balance at 30 June was TI'd into an Input Opening Balance at 1 July. The feeder linkages from 1 day to the next had a break introduced at 30 June. TI needs running annually, good numbers, got rid of the overflow messages.

Still not the neatest but workable. What I would like is a CFG parameter to bump up the feeder stack size when required.

Sample code below
# du 29/02/08
# 2 new lines in voucher type
# Calculated Closing Balance = n level CB - ruled
# Input Opening Balance = n level - to be TI-d in
['Calculated Closing Balance','D 30-06'] = n: ['Closing Balance'];
['Opening Balance','D 01-07'] = n:stet;
['Opening Balance']=N:
DB('Blah',
<17 dimensions!>
'Closing Balance',Attrs ('Days' , !Days, 'Prior'));
Feeders;
# du 29/02/08
['Closing Balance','D 30-06'] => ['Calculated Closing Balance'];
# du 29/2/08 change to NextWithGap to prevent feeder overflow
['Closing Balance']=>
DB('Blah',
<17 dimensions!>
'Opening Balance',
Attrs ('Days' , !Days, 'NextWithGap'));

Just an extra bit of info on this one.

We found that when the feeder stack overflowed on start up under 9.4 the server crashed. This is an acknowledged critical bug by Cognos.
Sorry I haven't got round to adding it to the bug section.
Cheers,

Are you using 9.4 in anger? Full marks for bravery

No,

We are migrating from v8 to 64 bit box and v9.
First step was to go to the 64bit box and 32 bit v8 and make sure all was OK.
Next step to v9 and 64 bit TM1.

We were testing the server under 9.4 since we wanted to make sure that the performance improvements we see on moving to the new hardware don't disappear under v9 which is alleged to be slower. I didn't want to promise performance improvements only to have them disappear when we move to v9....

Wanted to test on 9.4 since I think by the time we are ready to move to 9, 9.4 will be a sensible option for us. There's a fair amount of user interest in dynamic slice type functionality and didn't wanted to get into the 9.1 flavour of this since it's going to change.

Cheers,

I've been a bit shy about posting them here but we have some results from stress testing large retrievals from various TM1 versions, so herewith. This was retrieving (repeatedly) the same 250k of cells from the server. So (deliberately) not testing multi-write, dimension calcs or rules. Just retrieval. Same hardware (of course) and a lightly used developer network.


Average Time for 1 Machine
Version Average Time

8.4.5 49.62
9.0 SP3 u9 54.00
9.1 60.59
9.4 64.76

Shows a steady decline over versions.


Average Time for 3 Machines
Version Average Time
8.4.5 55.83
9.0 SP3 u9 59.21
9.1 56.24
9.4 63.99

Here 9.1 picks up - but 9.4 falls away again.
Think this might raise a few questions....