Debugging REXX checks

Naturally, we hope you'll never need this section and that all your checks will run perfectly the very first time. However, if you do run into trouble, the following tips can help:

Look at the documentation for System REXX errors: System REXX may put out some clues to the problem you are having with your checks. Look at the following documentation as appropriate:

See System REXX abend code X'050' information in z/OS MVS System Codes.
See the System REXX messages in AXR messages in z/OS MVS System Messages, Vol 3 (ASB-BPX).
See AXREXX Return and reason codes in z/OS MVS Programming: Authorized Assembler Services Reference ALE-DYN.

Look for clues to any REXX check problems in the system console log, the logrec data set, and the message buffer.

Make sure your REXX check writes debug information to REXXOUT when running in debug mode: When your REXX check runs in debug mode, the system will write information that can help in check debugging to a REXXOUT data set, if allocated. Information includes TSO error messages, System REXX error messages, and any information you write with the SAY keyword. See Using REXXOUT data sets.

Turn on debug mode: Writing code to capture great debug information in REXXOUT won't help if you don't put the REXX check in debug mode. When a REXX check runs in debug mode the system invokes the REXX check with a REXXOUT dataset. When a REXX check is not in debug mode, the system invokes the REXX check with no REXXOUT dataset, and the debug mode output is not saved

You can turn on debug mode for a REXX check using the DEBUG parameter in the MODIFY hzsproc command, in HZSPRMxx, or by overtyping the DEBUG field in SDSF to ON.

Unexpected data in your REXXOUT data set? If your check is running in debug mode, make sure the REXX check has exclusive access to the REXXOUT output data set. See Using REXXOUT data sets.