TM1 Forum

Here's what happens when we save a particular cube's rules file, about 500 lines long...

1) You receive the standard "Rule [cube name] already exists in server [server name]. Overwrite?" dialog. (Seemingly nothing unusual;) Click OK...
2) Excel goes out into space. If you click on the window, a "pre-office-2007" Excel window appears with "[Compatibility mode]" in the title bar. Click again and "(Not Responding)" gets tacked. (At this point, all excel windows, including anything opened from Perspectives, will show as 'Not Responding' in the Task Manager.)
3) 4 minutes later (and it's always about 4 minutes...we've tested it with different code commented out and/or removed) Excel returns and gives the error message that it "Cannot access [file name].xru"
4) After clicking OK, you're then prompted that "[file name].xru already exists in this location. Do you want to replace it?"
5) After clicking Yes, the files saves nearly instantaneously and any revisions that had occurred to the rules are in effect.

By contrast, another (much smaller) cube's rule file we have takes only about a second to go from giving you the message in (1) to the message in (4).

We've combed the forum for nuggets of info that might apply. That led us to look pretty thoroughly at the feeders. Nothing jumps out at us there. (That said, we have never been clear on how best to feed, particularly a formula involving division or if there are circumstances where you might need to specify more than one feeder for the same element?)

We have also...
rolled back to previous versions of the rules for the cube = no change
copied the code + deleted the rule file + created a new rule file + pasted in the code = no change
rebooted the server = no change

So we're curious whether people have encountered this before and how we might overcome it?

Four minutes isn't that unusual in itself. As you've already worked out a long save is generally due to feeders. To figure out specifically where your issue is I'd suggest you copy your rule text to a save location in a plain old text (or Excel) file, then replace your rule with just And try to save that. It should be less than one second to save. If you're having trouble with that then your problem is more likely to be network or some other non-TM1 issue. E.g. you may find that your rule file is set as read only for some reason.

If that simple rule goes smoothly then you have a problem with your feeders. Only foolproof way to find out where is to add in the feeders line by line, doing a resave each time. This will tell you which line is adding all the time and you can dig into that.

HTH,
Martin

I was skim reading a bit fast there.

fonthiller wrote: 3) 4 minutes later (and it's always about 4 minutes...we've tested it with different code commented out and/or removed) Excel returns and gives the error message that it "Cannot access [file name].xru"

This part I'm not sure about and is why I suggest you may have a problem with the file being read only.

Other than that you've just got a classic rule save. There's nothing untoward going on. You save the rule which takes four minutes (which will be feeders. This is not necessarily a problem, you may just have a lot of data flying around). Then what is going on is that TM1 sees you have an xru file as well as the rule you have just written directly in TM1. If the rule in TM1 gets out of sync with the xru file you can run into issues when someone opens up the xru and saves it, overwriting all the changes you've made.

So all that's happening in steps 3-5 is that the Excel (xru) file is getting updated to sync up with the actual rule file in TM1.

I've had rule saves that take 20 minutes (admittedly not since 32 bit days) so 4 minutes is not necessarily that bad. Still worth investigating of course.

Martin

Thanks Martin.

I also neglected to mention earlier that up until a few weeks ago, the file was taking only a few seconds to process. When it started to take longer, we were sometimes getting disconnected from the server while Excel seemingly went into radio silence. Now, we haven't been getting the boot from the server for the last 10 days or so, thanks to somethings our IT guys worked out, but that's not to say there couldn't be something else about the server and/or configuration?

On a recent project we were at the UAT stage and changes were coming through. I found that the most complex cube (30 pages of rules) was taking 1 hour 40 minutes to save on the dev environment. We were working away from base.
Solution:
a Make the change and save at 7pm
b Go for dinner
c Come back at 9pm, check change, apply to prod and restart
Worked quite well.

fonthiller wrote:I also neglected to mention earlier that up until a few weeks ago, the file was taking only a few seconds to process....

The time taken to save a rule file all comes down to the time required to process feeders. Feeders are dependant on input data and upstream calculations (ultimately all feeders have to start with input data).

If your rule is taking longer to save then it will be because you now have more data in the cube.