TM1 Forum

RuleLoadFromFile is causing me some headaches with inconsistant results when used within a chore compared to run in the TI on its own. While the TI blanks out my rules file correctly, the same TI when run as part of a chore doesn't so a later part of the chore fails. My current solution is to run the TI on its own first, then the chore but the way i see it this is really a bug :s

I have a complicated process to rebuild a dimension from multiple sources, so i have a chore with 14 TIs within it. One cube i have recently had to add uses the rebuilt dim, so during the rebuild it's rules cause the TIs to fail as elements are removed. Removing the rules first will solve that (overwritten with just SKIPCHECK;) but the TI doesn't work when embedded within the chore. Anyone have the same experience (TM1 9.5.2) or is there something i am missing?

Are there any meta data processes before it in the chore that could cause a lock in any way?

Steve Vincent wrote:RuleLoadFromFile is causing me some headaches with inconsistant results when used within a chore compared to run in the TI on its own. While the TI blanks out my rules file correctly, the same TI when run as part of a chore doesn't so a later part of the chore fails. My current solution is to run the TI on its own first, then the chore but the way i see it this is really a bug :s

Jim could be right about the locking. Another thing to consider is where you're doing this. In a Prolog, presumably? Have you tried having this in a process by itself which does nothing else but change the rules (and being the first process in the chore), with the change being done in the Prolog, and putting something in the Epilog just to force it across the Metadata barrier?

Already doing so - it's in a TI prolog that does nothing other than load the dummy rules file, and is the 1st thing to run in the chore. It's behaving like a single TI would - holding on to the original rules until the entire chore is completed.

Steve Vincent wrote:Already doing so - it's in a TI prolog that does nothing other than load the dummy rules file, and is the 1st thing to run in the chore. It's behaving like a single TI would - holding on to the original rules until the entire chore is completed.

Curious behaviour. I'd be inclined to raise that one with Support. In the meantime the only workaround that I can think of (other than the ol' 1-2 that you're doing at the moment) is using the chore to do the replacement then kick off RunTI or Mike Cowie's equivalent as a process which is external to the chore to do the remaining tasks... assuming that the Paranoids-That-Be allow you to do that kind of thing.

Have you tried "chunking" the chore into separate chores so that the unattaching and reataching of the rules is separate? (or else do an execute command from within a process in the chore to RunTI to do the rule clear and reattach in a separate thread?)

I just came across a situation where I needed to do this as one process in a chore was processing some text files which were used as a data source by a later next process in the chore. Seems the chore keeps a lock on the files until it completes so the downstream process failed as it was unable to open its data source. Single commit or multi commit mode didn't seem to make a difference to the chore releasing the file lock. Breaking into distinct chores fixed the problem.

Interesting you should mention that. Completely different TIs but i have an ASCIIDELETE in the epilog of a TI that uses the ascii file as it's datasource. While i get no error messages, it doesn't delete the file either. I suspect that may be hanging on to the source in a similar way. Even though a TI can run without it's datasource (as long as its created in prolog) it seems it's less happy to do the reverse...

Disappointed. Not surprised, but certainly disappointed.

No matter how i split it up, it refuses to load the rules file. Running them all in 1 TI, splitting them across the prolog / epilog, splitting in 2 TIs and running as a chore or chaining via another TI, they all fail. My only option has been to run them seperately. If ExecuteChore existed in 9.5.2 then that would be my last option to test it. Can anyone spare the time to test it with 10.1? I've neither the time nor facilities but there is no point in me raising it with IBM if its not a problem in 10.1 because i know what their solution will be

oh and i'm unable to use runTI as part of anything scripted due to the way our security is set up. I could only use it with my own account which would expose my password

That is a pain. I can't remember that last time a customer I worked with used chores. With the locking issues etc we to have moved to RunTI being kicked off by something Control-M in all cases.

The other thing that 10.1 has which might be of interest is CubeRuleDestroy.

Duncan P wrote:The other thing that 10.1 has which might be of interest is CubeRuleDestroy.

Is that a new function with 10.1?

Steve Vincent wrote:Interesting you should mention that. Completely different TIs but i have an ASCIIDELETE in the epilog of a TI that uses the ascii file as it's datasource. While i get no error messages, it doesn't delete the file either. I suspect that may be hanging on to the source in a similar way. Even though a TI can run without it's datasource (as long as its created in prolog) it seems it's less happy to do the reverse...

Yes, this has been the case since the year dot. I'm not entirely sure why it should be so since in some respects TI treats its 4 tabs as separate "procedures" and by the time you hit Epilog the source may as well be released since it's of no further use, but it isn't. That's why I switched to having a separate "clean-up" process run at the end of each chore (or string of process executions) which only handles things like archiving the data sources.

Steve Vincent wrote:oh and i'm unable to use runTI as part of anything scripted due to the way our security is set up. I could only use it with my own account which would expose my password

Oi vey. I understand the need for security, I truly do. But with each and every "can't do that, that is locked down" I hear about your place I do wonder if the Idiots-That-Be understand that for a system to be in any way useful it sometimes has to be allowed to, well, actually do stuff and that this necessarily involves a compromise between functionality and security. I don't know why they don't just put the computer (computer singular, and not networked) in a sealed concrete vault with no monitor, keyboard or mouse and run it off a huge car battery. For s'kurity, don'cha know.

lotsaram wrote:

Duncan P wrote:The other thing that 10.1 has which might be of interest is CubeRuleDestroy.

Is that a new function with 10.1?

Is that a subtle way of asking "Why exactly didn't this appear in the New features Guide"? It's because the Iboglix documentation department figure that we prefer the application to work more like a Kinder Surprise.

The only document that I can find it in is the 10.1 Reference Guide. I'll admit that I usually skim the reference guides when they come out but I must have missed that one, primarily because I've never needed to / had an inclination to monkey with the rules in that way. Doesn't help Steve since he's on 9.5.2 unless it was an undocumented feature in that release (wouldn't hurt to test that, but I suspect that it wasn't) but even if it is there's still the question of whether it would take effect from the time it runs, or the end of the chore (which would also need to be tested). I lack the time to do both at the moment but if anyone else would care to...

Re CubeRuleDestroy('');...

Alan Kirk wrote:The only document that I can find it in is the 10.1 Reference Guide. I'll admit that I usually skim the reference guides when they come out but I must have missed that one, primarily because I've never needed to / had an inclination to monkey with the rules in that way. Doesn't help Steve since he's on 9.5.2 unless it was an undocumented feature in that release (wouldn't hurt to test that, but I suspect that it wasn't)

Nope, spits the dummy in 9.5.2.

(Interesting coincidence; at the time of writing Steve Vincent was on 952 posts. Not sure why, but that just amused me slightly. Not greatly, just slightly. )

Does that mean that when he gets to 1011 he will have to upgrade?

Duncan P wrote:Does that mean that when he gets to 1011 he will have to upgrade?

His bosses probably won't let him. Adding bytes to the network via an installation package would be a sek-kur-it-ee risk. I'm amazed he isn't still on version 6 with Lotus 1-2-3 as the client.

We'll probably have to create another Forum account for him and just leave this one at 952.

His bosses probably won't let him.

Ah, I miss BAE

Garry don't tell fibs now!!

garry cook wrote:

His bosses probably won't let him.

Ah, I miss BAE

Is there a message behind your new avatar??

Nope, that's inspired by my purchase of XCom in Steam sale. Just need to find some time to play it