TM1 Forum

Using IBM Planning Analytics Local, Version 2.0.6

In the Metadata tab of the first TI Process, it calls a second TI Process with a string parameter. The parameter is a }Client ID which we call SSO.
I am attempting to use the ProcessExitWithMessage return code to know whether the SSO exists in a flat file or not.
Here is the calling code:

ReturnCode = EXECUTEPROCESS ( 'ADMIN - Security - Search GUIDE File for matching SSO', 'pSSO', vSSO );

# For debug use
ASCIIOUTPUT ( strLogFile, NumberToString(ReturnCode), NumberToString(ProcessExitWithMessage()), vSSO );

# If the called process wrote a line to the tm1 server log file, delete the current }Client
IF ( ReturnCode = ProcessExitWithMessage() );
IF ( DIMIX ( strClientDim, vSSO ) > 0 );
ASCIIOUTPUT ( strLogFile, 'Removed', vSSO, strFirstName, strLastName );
DELETECLIENT ( vSSO );
intCountDeletes = intCountDeletes + 1;
ENDIF;
ENDIF;



In the called TI Process, if the matching SSO is not found in the flat file, in the Epilog tab, it executes a LOGOUTPUT command to write a line to the tm1server.log file. For sure the writes to the server log file are occurring, I can see the appropriate lines in the tm1server.log file when the process is done. I tried different severity codes in the logoutput command, but no difference in behavior.

Here is the Epilog code in the called TI:

# If pSSO was not found in the GUIDE file, write a Debug messge to the tm1server log file
# which sends a specific return value to the calling process

IF ( strFound @= 'N' );
strMessage = GETPROCESSNAME() | ': Client ' | pSSO | ' not found in GUIDE file';

# Write line to server log file using DEBUG severity level
LOGOUTPUT ( 'DEBUG', strMessage );

# Try using INFO to trigger return code With Message
LOGOUTPUT ( 'INFO', strMessage );

# Try using WARN
LOGOUTPUT ( 'WARN', strMessage );

# Try using ERROR
LOGOUTPUT ( 'ERROR', strMessage );
ENDIF;


However, the ReturnCode seen in the calling TI Process is always a zero (ProcessExitNormal).
Even when the called TI writes a record to the server log file, the return code is zero.
It should result in a return code of 5.

Is there any secret to getting the ExecuteProcess return code to work when the return code should be ProcessExitWithMessage ?

Hi,

Bypassing the issue at hand for a while, why don't you use a global variable ? As in (in the calling process):
and in the called process:
Regarding the issue: are you sure that adding a line with LogOutput will change the outcome of the (called) process ? I'm not so sure about that. You would need to throw a ProcessError; for example.

Writing an entry to the server log in and of itself is not an error condition. I do this in all my dimension maintenance processes (to list out all the new members added from Oracle) and it does not create an error condition. Use Global Variables like Wim suggested. I use them all the time to do things like maintain error counts throughout all the chores in a process. I also use them to maintain a delimited list of error log file names so I can send an email at the end of the chore with all the TI error logs as an attachment. They work great for maintaining state between processes.

Wim Gielis wrote: ↑Thu Mar 07, 2019 10:49 pm Hi,

Bypassing the issue at hand for a while, why don't you use a global variable ? As in (in the calling process):

Code: Select all

NumericGlobalVariable( 'vFound' );
vFound = 0;
ExecuteProcess( '...' );

If( vFound <> 0 );
# ...
EndIf;

and in the called process:

Code: Select all

NumericGlobalVariable( 'vFound' );
vFound = ...;

Regarding the issue: are you sure that adding a line with LogOutput will change the outcome of the (called) process ? I'm not so sure about that. You would need to throw a ProcessError; for example.

I don't want the process to generate an error. According to the TI manual, using the logoutput command should cause the return code to be 5, but the return code is zero. I think it's a bug. Was just trying to see if anyone else has experience with this situation.

Wim Gielis wrote: ↑Thu Mar 07, 2019 10:49 pm Hi,

Bypassing the issue at hand for a while, why don't you use a global variable ? As in (in the calling process):

Code: Select all

NumericGlobalVariable( 'vFound' );
vFound = 0;
ExecuteProcess( '...' );

If( vFound <> 0 );
# ...
EndIf;

and in the called process:

Code: Select all

NumericGlobalVariable( 'vFound' );
vFound = ...;

Regarding the issue: are you sure that adding a line with LogOutput will change the outcome of the (called) process ? I'm not so sure about that. You would need to throw a ProcessError; for example.

As far as a workaround, yes, I will try using a global variable to pass the Found status back to the calling TI

jcr55 wrote: ↑Fri Mar 08, 2019 2:28 pmAccording to the TI manual, using the logoutput command should cause the return code to be 5, but the return code is zero. I think it's a bug. Was just trying to see if anyone else has experience with this situation.

Can you send a link please ?

I think you might be getting mixed up with ItemReject. AFAIK LogOutput should not cause any minor error status (in fact would be pretty bad if it did).

Wim Gielis wrote: ↑Fri Mar 08, 2019 2:51 pm

jcr55 wrote: ↑Fri Mar 08, 2019 2:28 pmAccording to the TI manual, using the logoutput command should cause the return code to be 5, but the return code is zero. I think it's a bug. Was just trying to see if anyone else has experience with this situation.

Can you send a link please ?

In the IBM PA 2.0 TM1 Reference Manual dated 05/23/2017, on page 319 it lists the Return Values from an ExecuteProcess command.
The called TI does write a line to the tm1server.log file via the LogOutput command. I do not want the called TI to exit with an error.
But I want the calling TI to get back the return code value equal to ProcessExitWithMessage(), which is 5.
But it is getting back a return code of 0 every time.

Return Values
ExecuteProcess returns a real value that can be tested against one of the following
return value functions:
Function Description
ProcessExitByChoreQuit() indicates that the process exited due to execution of the
ChoreQuit function
ProcessExitNormal() indicates that the process executed normally
ProcessExitMinorError() indicates that the process executed successfully but
encountered minor errors
ProcessExitByQuit() indicates that the process exited because of an explicit "quit"
command
ProcessExitWithMessage() indicates that the process exited normally, with a message
written to tm1server.log
ProcessExitSeriousError() indicates that the process exited because of a serious error
ProcessExitOnInit() indicates that the process aborted during initialization
ProcessExitByBreak() indicates that the process exited because it encountered a
ProcessBreak function

lotsaram wrote: ↑Fri Mar 08, 2019 3:38 pm I think you might be getting mixed up with ItemReject. AFAIK LogOutput should not cause any minor error status (in fact would be pretty bad if it did).

I agree that LogOutPut should not cause an error status.
The way I interpret the TM1 Reference manual is when LogOutPut command writes a message to the tm1server.log file, the TI return code should be set to 5 (i.e ProcessExitWithMessage). But the calling TI is getting back a return code of zero every time.
I do not want the called TI to end with an error status, I just want the calling TI to know whether the called TI executed the LogOutPut command or not.

I will pursue using a global variable instead of the return code...

jcr55 wrote: ↑Fri Mar 08, 2019 3:57 pm

lotsaram wrote: ↑Fri Mar 08, 2019 3:38 pm I think you might be getting mixed up with ItemReject. AFAIK LogOutput should not cause any minor error status (in fact would be pretty bad if it did).

I will pursue using a global variable instead of the return code...

Yes because the software... will not do this, changing the return code, as was argued before.

Wim Gielis wrote: ↑Fri Mar 08, 2019 3:58 pm

jcr55 wrote: ↑Fri Mar 08, 2019 3:57 pm

lotsaram wrote: ↑Fri Mar 08, 2019 3:38 pm I think you might be getting mixed up with ItemReject. AFAIK LogOutput should not cause any minor error status (in fact would be pretty bad if it did).

I will pursue using a global variable instead of the return code...

Yes because the software... will not do this, changing the return code, as was argued before.

Using a global user variable worked.
Thank you all for your help!