FeedString causes the server to crash

[anoops81]

Hi ,

I have used the following rules in the cube

Code: Select all

Feedstrings;
Skipcheck;
['Origination Year' ]  = S:SUBST(DB('Debt_Forecasting', !Collateral, !Index, !Ess_Accounts, !Ess_BSLA, !Ess_Timeperiods, !Ess_Years, !Ess_Scenario, !Ess_Product, !Ess_Entities, !Ess_DTS, !Ess_CorpCode, !Ess_Currencies, !Currency Type, 'Origination Date'),
7,10);


Feeders; 
['Origination Date'] => ['Origination Year' ];

When I try to save the rule , the system is not responding and Memory consumption keeps on increasing, finally I have to end the tm1 server service and start it again .

The Debt_Forecasting cube is a big sparse cube .
I tried to save it with out feedstrings and it was saved, but suppress zero will dissapear the Origination Year as it is string.

When I tried to implement the feedstrings on a small cube with few elements it was working fine.

I was not able to identify the issue . Am I over feeding here ? Or the system is crashing due to large number of dimension elements ? I have not loaded any data into the cube. Just for testing purpoes we have entered a date value into the ['Origination Date'] measure .

We are on TM1 9.5.2 HotFix 5 .

Any suggestions are much appreciated .

Thanks,
Anoop

[John Hammond]

It is the SUBST function. Change it to take a length of 4 not 10.

[anoops81]

Hi John,

I corrected the length to 4 . But still not able to save the rule. Getting error message " Rule update failed".


Regards
Anoop

[John Hammond]

Remove the rules from the cube, recycle the server, re-add the rules with the length of 4 and I am 99% certain this will work.

[anoops81]

Hi John,

I have tried that option also. But with Feedstrings it is still crashing. Which version of TM1 you using ?

Regards
Anoop

[John Hammond]

I on 9 but that should not make too much difference on something like this unless you are using that new persistent feeder option.

You are right that overfeeding will cause a crash but your code is fine in that respect and otherwise a server crash comes about through a wrongly coded function call / bad rule.

Try getting it to work without the function call as only a direct assignment.

[anoops81]

Hi John,

We had the persistant feeder option enabled. I disabled it and I was able to save the feedstrings statement. But now Feeder statement is causing the server crash.

Code: Select all

FEEDERS;
['Origination Date'] => ['Origination Year' ];

Regards,
Anoop

[lotsaram]

Why do you need to feed this rule at all?

I don't think persistent feeders would have anything to do with what you are experiencing. For what its worth I have noticed issues with feedstrings in both 9.5.1 and 9.5.2 where if you attempt to feed a string TM1 doesn't respect the non-empty intersections on the LHS of the feeder and basically feeds every intersection for the string value which can lead to massive rule save times and server going out of memory if you don't have enough. Given the number of dimensions in your debt forecasting cube you wouldn't want to make this cube dense!

Don't forget that
1/ strings don't consolidate
2/ Tm1 doesn't cache rule derived string values so they are always re-evaluated on each query

Therefore the ONLY reason for using feedstrings is if the rule derived string values absolutely must display in a zero suppressed view. Usually you can design reports around this requirement by limiting the null suppression to only rows or columns and/or including other measures that are populated or using another interface other than the cube viewer. If you can do away with feeding the strings then you do away with your issue. Provided you got the order of dimension correct in your DB and both Origination Date and Origination Year are defined as string elements then there doesn't look to be anything wrong with the rule itself.

[anoops81]

Hi Lotsaram ,

Why do you need to feed this rule at all?

I was checking for "Origination year" after suppress zero's . It was just disappearing in the debt_forecasting cube. When I was testing in a small cube, string value is apprearing even after suppression .

For what its worth I have noticed issues with feedstrings in both 9.5.1 and 9.5.2 where if you attempt to feed a string TM1 doesn't respect the non-empty intersections on the LHS of the feeder and basically feeds every intersection for the string value which can lead to massive rule save times and server going out of memory if you don't have enough.

Now I understood the issue. Feedstring is working for small cubes but not the ones with more dimensions.

Usually you can design reports around this requirement by limiting the null suppression to only rows or columns and/or including other measures that are populated or using another interface other than the cube viewer.

I will go with suppress zero only to rows/columns.

Thanks,
Anoop

[John Hammond]

For what its worth I have noticed issues with feedstrings in both 9.5.1 and 9.5.2 where if you attempt to feed a string TM1 doesn't respect the non-empty intersections on the LHS of the feeder and basically feeds every intersection for the string value which can lead to massive rule save times and server going out of memory if you don't have enough.

Just went and did some checks on this with 9.0 and it respects non empty intersections so I would suggest that this drastic change of behaviour could be deemed a bug though convincing Iboglix is another ballpark altogether.

The test is relatively simple btw create
dim1 = {a,b}
dim2 = {S-meas,S-meas2}

Code: Select all

# test cube rules
feedstrings;
skipcheck;
# nb have to code rhs of string rule as DB
['S-meas2'] = S: DB('Test',!dim1,'S-meas') ; 

feeders;
['S-meas'] =>['S-meas2']  ; 

Go into the cubeviewer and enter a value against a and then start performance monitor.

If you get 2 fed cells then its feeding the entire area regardless. If you get 1 things should be oK

Would be interested to see what 9.5X users get.

[anoops81]

Hi John,

I have tested it in 9.5.2 HF 5.

I am getting 2 fed cells for a single string entry. Screen shot below.

Test_Cube.JPG (13.4 KiB) Viewed 9552 times

stats_cube.JPG (18.77 KiB) Viewed 9552 times

Anybody knows whether this is already logged as a defect with IBM ?

Regards,
Anoop

[John Hammond]

Thanks Anoops - here is the result in 90. It is the correct one and this illustrates that there is a severe bug in 951/952 as LotsaRAM has pointed out. So the upshot is dont feed strings in 95 until they have corrected the problem. I cant raise the bug myself as I am on 90 but a URL to this example should be enough for IBOGLIX to reproduce the bug themselves and fix it in time for Release 11.