@sf-mensch A question.
Assume that the program dispatched by the call to cob_call_with_exception_check
ends normally - sort of.
The application set the return-code to 4, 8, 12 or whatever.
The point being that the -fec=data in my example was not detected.
If no interrupt was detected, but I invoked the application via cob_call_with_exception_check ,is there a way that I can determine the return-code that was set by the application program.
I have experimented with what Chuck provided, tailored it a wee bit but alas I can' find a method to determine the application return-code.
If either of these conditions below occur it would be beneficial to pass the return-code on to the JES / JCL emulation subsystem.
switch(ret){case0:/* program coming back */break;case1:/* normal exit */break;
cob_last_exit_code always seems to return zero - irrespective of what the called application set the return code .
Please advise.
Thank you,
Ralph
ret=(ptr_char,1,cob_argv);switch(ret){case0:/* program coming back */break;case1:/* normal exit */break;case-1:/* error exit */break;case-2:/* hard error exit */cob_runtime_hint("hard error exit with return code %d and error \"%s\"",cob_last_exit_code(),cob_last_runtime_error());break;case-3:/* signal handler exit */cob_runtime_hint("signal handler exit with signal %d and error \"%s\"",cob_last_exit_code(),cob_last_runtime_error());break;default:break;}
Last edit: Simon Sobisch 2023-05-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The internal static variable exit_code which you get by cob_last_exit_code is set by the return code of the function executed with cob_call_with_exception_check.
And if you don't do something special then the program returns the value of the RETURN-CODE special register (must be size of an int).
The testsuite also verifies that this works. Other than the size of an int - ensure that you directly read the last exit code after coming back from the called function - otherwise it is likely to be overwritten, for example it is reset when you execute cob_tidy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@sf-mensch
I used this and it functional
Thank you !
switch(ret){case0:/* program coming back */ret=(cob_last_exit_code());break;case1:/* normal exit */ret=(cob_last_exit_code());break;case-1:/* error exit */break;
Last edit: Ralph Linkletter 2023-05-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@sf-mensch A question.
Assume that the program dispatched by the call to cob_call_with_exception_check
ends normally - sort of.
The application set the return-code to 4, 8, 12 or whatever.
The point being that the -fec=data in my example was not detected.
If no interrupt was detected, but I invoked the application via cob_call_with_exception_check ,is there a way that I can determine the return-code that was set by the application program.
I have experimented with what Chuck provided, tailored it a wee bit but alas I can' find a method to determine the application return-code.
If either of these conditions below occur it would be beneficial to pass the return-code on to the JES / JCL emulation subsystem.
cob_last_exit_codealways seems to return zero - irrespective of what the called application set the return code .Please advise.
Thank you,
Ralph
Last edit: Simon Sobisch 2023-05-09
The internal static variable
exit_codewhich you get bycob_last_exit_codeis set by the return code of the function executed withcob_call_with_exception_check.And if you don't do something special then the program returns the value of the
RETURN-CODEspecial register (must be size of an int).The testsuite also verifies that this works. Other than the size of an int - ensure that you directly read the last exit code after coming back from the called function - otherwise it is likely to be overwritten, for example it is reset when you execute
cob_tidy.@sf-mensch
I used this and it functional
Thank you !
Last edit: Ralph Linkletter 2023-05-09