TM1 Forum

Hi all,

Need some clarity on the RunProcess return value. I have setup some validation in the sub process and if something goes wrong, it will add up the error counter and ProcessBreak. This will skip everything and goes directly to Epilog (here I have some important procedure to remove some generated files), and at the end of Epilog, if the error counter is > 1, then it will do ProcessError.

In the main process, I'm trying to capture the result of the RunProcess function like so:
Return_Value = RunProcess (cProcess, 'Organization', 'CT2')

When I ASCIIOUTPUT the return value, I am expecting empty string to be returned, surprisingly the job IDs are returned.

Referring to IBM doc on RunProcess function, it says 'The string is the JobID, or an empty string if an error occurs.'

Can anyone help me to understand what am I doing wrong here.

Thank you.

The 'error' in 'The string is the JobID, or an empty string if an error occurs.' is an error with the call to the RunProcess function itself (e.g. non-existent process, mismatched parameters etc), not an error in the process that RunProcess is calling. As soon as the RunProcess function successfully starts the process being called, the JobID is returned and the calling process moves on to the next line of code, regardless of whether the called process has completed or not. There is therefore no way for the called process to directly pass any status back to the calling process.

The fact that you are getting a JobID returned shows that the RunProcess function has successfully initiated the called process, nothing else.

If you are sure that it is RunProcess that you need to use rather than ExecuteProcess (where the calling process waits for each called process to complete before moving on to the next line of code, and the return value does reflect the status of the called process), then it is up to you to add code to the called process(es) so that they identify whether they have had errors or not. Depending on your system, this could be using methods such as a status cube, synchronize, text files or by parsing the response file for the relevant JobID.

Assuming that the calling process is expected to take varying actions depending on the return values, you will also need code in the calling process that waits for all of the called process(es) to complete before it takes that action. This waiting can be controlled by the same method that you are using to identify the state of the called process(es).

I think you might be confusing RunProcess (runs in parallel on a new thread in new transaction) with ExecuteProcess (runs in serial in same thread in same transaction).

If you want the calling process to wait for the sub-process and easily read the status of the sub-process then using ExecuteProcess is the simplest way (by far). Which isn't to say it isn't possible to use RunProcess and have the main process wait for completion and read the status, but as Andy already hinted, to do this you need to design in a wait mechanism with semaphores and a mechanism for the sub-process to write out a status message somewhere (cube, file, RDBMS) and for the calling process to be able to retrieve the message.

For the case you describe using ExecuteProcess seems much simpler. ExecuteProcess will return a numeric integer value of the ProcessReturnCode.