equivalent to commenting out

[telula]

Hello,
In sql, you can commen out chunks of code with /* ... */
I need to find the equivalent in TM1. I know I can use stet.

For example, I have rules
[Labour Hours]: ....
[Labour Rate]:...
[Holiday pay]:...
[Sick pay]:....

I want to 'turn on' the rules for [Labour Rate],[Holiday Pay] and [Sick Pay] only at month end.Is there an efficient way to STET them out? Because my cube rules has lots of calculations that I need to stet out.

Can anyone help?

[kpk]

Hello,
You can use # to turn off statements both in Rules and TurboIntegrator processes.
Regards,
Peter

[kpk]

Or
1)
You can use rule worksheets (Excel version of TM1 rules with xru extension).
When you save a xru TM1 compile only the column "A" so you can move statements into the "B" column to turn them off.
And you can make 2 version of rules in one workbook and just open and save the one you need.
2)
You can attach rules via TI process (RuleLoadFromFile(Cube, TextFile);). So you can have 2 version of rules and change them from (eg. scheduled) TI.
3)
You can also turn your rules out/on by STET function which can be turned on/off by changing a cell in a lookup cube.

[Steve Rowe]

Or
Write the rules with an if statment and reference to a control cube

[blah] = N: If (Db('Control' , 'Flag', 'Rulesactive')= 1, blah, stet);

Then you can change the 1 to a 0 in the control cube to de-activate your rules or vice versa.

Having to maintain your ruels every month doesn't seem like a good approach. Also I'm not sure why you want rules to be active as certain times, I'b be intersted to hear of the business reasons for this if you would like to share.
HTH

[telula]

Hello Steve,
The reason for turning off the rules is because end users are complaining about the speed.
We have cubes just for project management and 1 cube that calculates income based on the other 2 cubes. The income calculation only happens at month end.So I am hoping that if I turn off the rules that calculates the income during normal days, it is faster for endusers to enter their forecasts.The endusers enter the forecasts through an excel interfaces that uses mdx query.Do you have any other suggestions to increase the speed?

[Steve Rowe]

Hi Telula,

Well if the performance issue is related to the design of your TM1 application rather than infrastructure issues (things like network, data entry environment, server hardware) then the only thing that will slow down data entry alone is the fireing of feeders. So to test your theory commenting out the feeders should be the first step rather than the rules.

Your situation.
You have cubes A and B and calculation cube C that is dependant on A and B.
When data is entered into A and B the performance is too slow.

I think you probably need to consider what else is happening at the same time as the data entry. If people are constantly asking for results from Cubes A, B and C at the same time as data entry then you will see the worst performance your environment can deliver because TM1 is constantly recalculating the results and then discarding them all as soon as another person enters a number. Other than that the only thing that happens in TM1 when a user enters a number is that a feeder may fire.

So unless people are asking the system to calculate the income (or a dependant of income) at the same time as data entry then commenting out the rule won't make any difference, that's obvious I suppose. From a purists point of few I would not want to comment out a calcualation because I can't make it work fast enough for the users. I'd look harder at the calculation and the feeder for the calculation to ensure that it is set up optimally first.

I've not used MDX very much but I would imagine your excel template has a signifcant overhead vs a more static environment.

I'm not sure how much investigation you have done as to the cause of the slow down but I would probably spend a lot more time watching and investigating the users so that I could understand in detail what the performance issue is. Then you can provide a more targetted solution. You could spend a lot of time fine tuning the TM1 system and find that the issue relates to the use of the MDX in the workbook and it takes too long for the MDX to generate the subsets. If your MDX subsets are dependant on the data that is being entered for example I would have thought that your environment would get in nasty circle of churn.

HTH

[nhavis]

Note that rule-driven cells will not retain their rule-driven values once you remove the corresponding rule (ie. your users won't be able to grab values from the cube because they won't be there).

[Alan Kirk]

Note that rule-driven cells will not retain their rule-driven values once you remove the corresponding rule (ie. your users won't be able to grab values from the cube because they won't be there).

That isn't necessarily correct.

What IS correct is that the values will become unpredictable. The rule-driven amounts may remain, or they may not.

http://forums.olapforums.com/viewtopic. ... 483&p=2948

[nhavis]

That's right, you shouldn't rely on the contents of your cells after you have removed the rules.

I have not experienced the rule driven values remaining in those cells after a rule is removed, I suppose it's possible as they could remain in RAM. However it's not possible that the same values remain after a server restart as rule calculated values do not get saved to the .cub file (unless exactly matching data was previously entered manually).

[Alan Kirk]

That's right, you shouldn't rely on the contents of your cells after you have removed the rules.

I have not experienced the rule driven values remaining in those cells after a rule is removed

It does seem to be version-dependent.

I suppose it's possible as they could remain in RAM. However it's not possible that the same values remain after a server restart as rule calculated values do not get saved to the .cub file (unless exactly matching data was previously entered manually).

You may want to re-read the first couple of posts in the thread; that's exactly what happened in at least one version, and with more than one user. The fact that the values persisted in memory after the rules were removed would seem to have been enough to fool the server into thinking that they were input values.

[Steve Rowe]

Without wanting to hijack the thread too much.

If you write rules for an area that already contains input values on some releases you get the input values back if you remove the rules. I've never seen the the ruled values themselves retained after a rule has been commented out.

Cheers,

[Alan Kirk]

Without wanting to hijack the thread too much.

If you write rules for an area that already contains input values on some releases you get the input values back if you remove the rules. I've never seen the the ruled values themselves retained after a rule has been commented out.

You ain't used 8.2.12 then.

The situation that I described in the thread that I linked to in an earlier post was exactly that. The 81500 elements had never in their lives had direct input; they were rule-based since they day they were created. Prior to the deletion of the rule, they had been entirely rule based yet they retained their values after the rule was deleted.

[nhavis]

Without wanting to hijack the thread too much.

If you write rules for an area that already contains input values on some releases you get the input values back if you remove the rules.

I've also seen them disappear after some sort of refresh which I haven't been able to replicate.