Master Process aborts when nested process fails

[7Zark7]

Hi All,

I have a Master process that kicks off a whole heap of other TI processes using the EXECUTEPROCESS function
however when it encounters a TI that errors it aborts the Master process and does not continue onto the next TI process unlike a chore.

Is there a way for the process to keep on going to the next processes without it aborting??

Cheers

Zark

[lotsaram]

You need to give an actual example of the code you are using, what the called process is doing (including maybe the code) and the error that is in tm1server.log and the process error log.

Usually "shelling out" to another process can actually be a god way of avoiding a process quitting as the major error happens in the called process and the calling process continues just reporting that the sub.process encountered an error.

If the whole thing is aborting then you probably have a major error that you need to debug and handle in any case.

[7Zark7]

Hi Lotsa,

Thanks for the feedback. The error is in relation population of attiribute values for a personnel dimension,where and element shares the same attribute value, so when the data attribute value is being populated it cannot populate it since it already exists.

So just a general question, if a sub process fails regardless of whether its nasty or not, will the subsequent processes run or will they stop ( this is what I have found ), BUT does it depend on severity of the fail? i.e. if its a minor error will it just continue on?

Since this morning load needs to continue on regardless of whether there is an error in process ( like a chore ) is there and equivalent to cmd line utility like RUNTI but for chores i.e. RUNCHORE??. If so can you point me where i might be able to find this tool?

Cheers

Zark

[declanr]

By default the master process will be fine to continue and just report minor errors itself if its sub processes have minor errors. You can however use the process returned value to quit the master process on any error if you desire.

[Steve Rowe]

Your best bet is to properly trap and test for the error before it occurs rather than try and run your code such that a fatal error has a lower impact.

I think you are trying to update an alias (rather than an attribute) and sometimes the alias value already exists as an element?

If so suggest you do a dimix test on the alias value before you update the dimension, if the dimix test returns greater than 0 then don't do the update operation.

HTH
Cheers,

[7Zark7]

Thanks Steve, yep that will fix it.

However I always thought that in the event of
Any error sub processes fired from within
A master process using the Executeprocess function
the master process would still continue on. I
was surprised that this was not the case, even
If the sub process aborted in the case where it is fatal.

Since, the master process executes in sequence
roughly 80 processes which form the part of our
Morning load it is essential that all processes
Continue on regardless of the prior state of the previous
Process. Running a chore essentially bull dozes
It's way through regardless of the state of the
Previous process and in this circumstance is safer
IMO. I agree that fixing the root cause is
Important here and substantial time will be required
To build this in. But in this case running this via a chore
( Via mike cowies cmd line tool ) Taking into account all the benefits of running
This in a master TI comes up trumps for me.