On 05/19/2015 07:16 PM, Shmuel Metz (Seymour J.) wrote: > In <[email protected]>, on 05/14/2015 > at 09:17 AM, Joel Ewing <[email protected]> said: > >> I think we resolved the issue by converting the CLIST to REXX so >another >> TCB was involved. > > How is that relevant? What is relevant is how you dealt with ERROR and > FAILURE in the REXX code. > >
My recollection is that the immediate bailout from the CLIST and from batch TSO on a non-zero TSO command processor RC only occurred for commands running "directly" under the batch TMP TCB (and running a CLIST command directly from SYSTSIN was actually causing all TSO commands within the CLIST to run at that level as well!). When executing TSO commands from a REXX exec invoked from SYSTSIN that was not the case, and premature termination of the REXX exec and batch TSO did not occur when TSO SEND was invoked within the EXEC and gave a non-zero return code. The replacement REXX EXEC produced a zero return code for the entire EXEC based on its own internal criteria, which did not involve checking the RC from SEND. We found the premature bailout difference in behavior between CLIST and REXX environments unexpected and counter-intuitive, but it seemed to make perfect sense to those at IBM TSO support familiar with TSO internals. I accepted IBM closing our problem as a DOC change: the TSO manuals at the time did document this behavior, but in a way that required a TSO internals specialist for correct interpretation. The root cause of our problem was that TSO SEND (working as designed with user log files) was returning a non-zero return code when it actually did NOT have an error and when message delivery eventually succeeded. An actual "failure" of the requested SEND command action was not an issue, and it was unnecessary to do anything special to handle an ERROR or FAILURE of SEND in the REXX Exec. The nature of the original CLIST in question was such that a failure to execute statements in the CLIST following the SEND was a much more serious problem for us than if the message had just failed to reach its intended destination, which did not occur. In our case the end user would eventually have detected loss of an expected confirmation message on his own and followed up if that had occurred. -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
