TM1 Forum

Hi

I have a client testing a model on a local server and they are getting totally different results for consolidations on a local server than I see when running it as a remote server. I have checked here and see the same difference. 9.1 SP2 U3

I am guessing that this has to do with the AllowSeparateNandCRules=T TM1S.cfg setting, which if i recall doesn't get read when you start a local server (of course not - why would you want a local server to behave the same way? )

Anyway - if anyone can confirm that this is expected it would be very helpful.

TIA

John

Ages ago when we used 8.1.8 i remember seeing local servers with different numbers to that of a "real" server. We've never used local servers since, its just not worth the aggravation

Cognos confirmed this issue does exist, is reproducible, and that it is not fixed in the current release.

When is a rule not a rule?
When it's executed by a local server? Hmmmm

I can confirm that the AllowSeparateNandCRules parameter issue still exists on a 9.4.1 FP3 local server....

Config file parameters are ignored for local server so there will inevitably be some discrepancies in behaviour.

HOWEVER if you are specifically seeing discrepancies in calculation results due to the use of AllowSeparateNandCRules=T then surely the the simple solution would be to shake your old dinosaur bones and re-write the rules to post version 7 syntax!

That is rather than this
['Area'] = N: .... ;
['Area'] = C: .... ;

Re-write as this
['Area'] = N: .... ;
C: .... ;

The example you have given is really a special case where the LHS of the N and C part are the same, it's usually not as simple, though.
[AreaA]=N:
[AreaB]=C:

AreaA and AreaB partially overlap in some way. You then have to specify additional Ifs in your C level rule for AreaA where A and B intersect, potentially even adding attributes to the system in order to be able to do this.

[AreaA]=N:
C: If ( AreaA is a member of AreaB, blah, stet);
[AreaB]=C:

Giving a more complex set of rules

That change in syntax when it was introduced really added nothing (unless a non-AllowSeparateNandC server runs faster?) and just made writing rules harder by introducing restrictions on what the LHS could talk about. Never really saw the point. I don't really think that it's a case of this being an "old fashioned approach", it's more a case of it being a more practical way of writing rules.

Irrespective of that, it doesn't seem sensible that a local server should ignore the cfg parameters. Maybe you could argue it's a license thing, since local/perspective servers are intended as single use stand alone servers, so why would you want all the cfg stuff. If you need a development server buy a development license. Who knows what was going in the Applix corporate brain!
Cheers,

Hi Steve,

A bit of healthy debate is always worthwhile!

I would say that mostly, if not almost always, that separate N and C rules do apply (or can be made to apply) to the same cube area. Normally this is in a budgeting/planning type scenario where at N level you have something like volume and price per unit. At N level unit price, COGS, GP, etc. is an input or lookup from another cube whereas at C level you need to monitor the effects of product mix on margin and need to calculate average price per unit and mix effects.

This might be over-simplified, but in dozens of TM1 models across a variety of industries I am yet to see a separate N and C rule that could not be combined into a single area statement. I'm not saying that such situtions don't exist, only that it is extremely rare in practice to require a true multidimensional calculation with overlapping areas over N and C cells.

Where such a requirement does exist it could usually be solved by splitting out to more discrete area statements. If anyone has an example where separate overlapping N and C rules are the only viable option I would be really interested in those examples.

I agree on your comments about about local servers & config parameters, probably more than a grain of truth in those aspersions.

Hi lotsa!
Debate rules, especially before you've had your first coffee!
As ever with TM1 you can make it do what you want how you want.

I just feel that being forced to write the N and C in exact area pairs is unnecessarily restrictive and does not seem to bring any benefits at all. If putting the NadC para in slowed TM1 down by 10% then a case could be made for not using it.

Anyone done any testing or noticed any benefits of not using the parameter? When building a new application it's usally the first thing I put in the cfg file. Hope they never stop supporting it.....

Cheers

Altough you can achieve the same rule by using complex conditional rule statements using ISLEAF and DTYPE functions, I agree that using AllowSeparateNandC=T gives extra flexibility and freedom in writing rule statements for overlapping area definitions.