TM1 Forum

Andy Key wrote:I've just had a look at that document and thought I would give it a go as I haven't touched DR yet.

Apart from the fact that the code doesn't save due to a missing '1' on the RHS of the Control Cube check line, and the fact that the resulting DRsummary cube will only show the first DR for a }Cube/}Client combination not the complete list as the description of 'all the data reservations on all available cubes in a TM1 server' suggests...

So... not so much a "Proven" practice as a "Hopeful With Fingers Crossed" Practice, then.

(I'm so very glad that I qualified the original post. It sounds like the problem that the code was intended to address is a valid need, though someone will have to sit down and solve it properly... when or if the time is available.)

According to experience [ConsolidatedMin, ConsolidatedMax, ConsolidatedAvg, ConsolidatedCount, ConsolidatedCountUnique] do not calculate correct without SKIPCHECK.

ConsolidatedMax and ConsolidatedMin (I haven't checked the others) can also give incorrect values if a dimension element appears more than once in the same hierarchy.

So funny you guys are talking about ConsolidatedAvg etc, Just trying to use it now for training material... I can't get it working. The IBM article here says it works with TI and Rules.

Here's what I've tried:
Scenario 1: Ignores the N: Level Rule - The result of ConsolidatedAvg is #NA (not sure why as I'm looking at Subscription Price measure in both lines)

Scenario 2: Ignores the C: Level Rule, C Levels are naturally consolidated.

Scenario 3: Same result as Scenario 1:

Scenario 4: In this case the measure at every level is #NA.

Tracing any of the cells calculating to #NA(using the ConsolidatedAvg) rule will show the value of 'Subscription Price' perfectly then state that the rule resulted in -1.#IND which is usually whats returned from an infinite loop - none here though.

I really wanted to try the new functions...

Any ideas?

The results are what I would expect, unless you have the AllowSeparateNandCRules=T set in your .cfg file. Do you?

Yep, right on the money, was playing around in sdata. But that still doesn't fix my real issue which is with ConsolidatedAvg.

I know there is at least one bug in ConsolidatedAvg function -- supposedly will be fixed "in the next release" (per email I received 4 Jul 2011).
Using flags in the parameters, does not always return correct value.
Perhaps there is something more wrong with it as well?
https://www-304.ibm.com/support/entdocv ... wg1PM42139

Stumbled across this while testing the use of PI for high volume calculations.

There was a feeder in the main calculation cube on the lines of Clearly not correct (the 2nd ref should have been to Life2 Age).
Under CX90 (aka TM1 9.4.1) and CX95 (aka TM1 9.5.1) no error was reported (but the feeder almost certainly didn't work).
Under TM1 9.5.2, the rules engine (correctly) flagged it as an error.
Don't recall changes to rules validation being highlighted in the release docs, so thought it worth bringing to the community's attention.
Support have confirmed the change (while disagreeing that it is an inconsistency ) and also cited
https://www-304.ibm.com/support/docvie ... g21568274

David Usherwood wrote:Stumbled across this while testing the use of PI for high volume calculations.

There was a feeder in the main calculation cube on the lines of

Code: Select all

[
'Life1 Age':'All Ages',
'Life1 Age':'All Ages',
<blah blah> ] =>

Clearly not correct (the 2nd ref should have been to Life2 Age).
Under CX90 (aka TM1 9.4.1) and CX95 (aka TM1 9.5.1) no error was reported (but the feeder almost certainly didn't work).
Under TM1 9.5.2, the rules engine (correctly) flagged it as an error.
Don't recall changes to rules validation being highlighted in the release docs, so thought it worth bringing to the community's attention.
Support have confirmed the change (while disagreeing that it is an inconsistency ) and also cited
https://www-304.ibm.com/support/docvie ... g21568274

Have also noticed this as part of our 9.5.2 upgrade. Basically any erroneous second and subsequent references to the same dimension within square brackets (or element references beyond a single instance not within the curly braces signifying an element array) were previously ignored by the rules syntax checker but are now (correctly) picked up. I wasn't too concerned about it since it corrected what was previously an unnoticed bug and allowed us to pick up a handful of likewise unnoticed errors in some rules.

I don't quite see how IBM would see it as not being an inconsistency though! ... and the support link also would seem to me to be talking about another tightening of the rules syntax checker versus the one you pointed out.

I found a rather annoying bug in 9.5.2 x64 at least (don't know whether it also occurs in 9.5.2 x86)

Problem description

Process 1 calls (executeprocess) Process 2 that does metadata updates.

=> Metadata is not updated.

FP1 seems to fix this though.

Jeroen