Prior to z/OS V2R1, REXX messages (IRX messages) could not be trapped. In z/OS V2R1, TRAPMSG is a new TSO/E REXX function used in conjunction with OUTTRAP to permit REXX to trap REXX messages (‘ IRX’ messages) in some instances.
You use TRAPMSG('on') to tell REXX to treat REXX message output in the same way as any other output for purposes of trapping.
REXX messages issued by nested execs and by host commands invoked by REXX (EXECIO) can now be trapped into an OUTTRAP variable rather than always being written to the screen. Also, CLIST error messages from CLISTs invoked by REXX can also be trapped
The TRAPMSG function syntax is as follows:
- TRAPMSG() Returns current setting.
- TRAPMSG('ON') Enables output trapping for IRX messages.
TRAPMSG(‘'OFF') Disables output trapping for IRX messages. Default is 'OFF’
Here's an example of a REXX exec that invokes EXECIO without allocating the INDD file.
- EXECIO will return RC=20 and an error message.
- By trapping the message with OUTTRAP, the exec can decide what to do with the error.
This same technique can be used to trap the IRX0250E message if EXECIO was to take an abend, like a space B37 abend.
The output will be:
Here's an example of a nested exec.
- A REXX exec (exec1) turns on OUTTRAP and TRAPMSG and invokes a second REXX exec (exec2) as a command.
- The second REXX exec gets an IRX040E message due to an invalid function call.
- Exec1 is able to trap the message issued from exec2.
Here's the output.
Note that if exec1 had made the bad function call, it could not trap the error message because a function message is considered at the same level as the exec.
This is similar to the fact that an exec can use OUTTRAP to trap SAY statements from an exec that it invokes, but it cannot trap its own SAY output.
Invoking as a command vs. invoking via the CALL keyword:
When an exec is invoked as a command as shown in the previous example:
- A non-zero return code in the second exec (exec 2) does not terminate the invoking exec (exec1).
If a function or subroutine is invoked via the CALL keyword and the function or subroutine ends with a non-zero return code,
- Although the output is trapped, additional code will be required to deal with the function or subroutine error.
- Invoking it via a CALL without the additional code causes the invoking exec to terminate if the function or subroutine has an error.
Here's an example of some code which avoids termination of the REXX exec which calls another exec.
The output is shown here.
For more information on System z and the z/OS operation system see the following IBM Redbooks publications:
ABCs of z/OS System Programming: Volume 1, SG24-6981-02
ABCs of z/OS System Programming Volume 2, SG24-6982-02
ABCs of z/OS System Programming Volume 3, SG24-6983-03
ABCs of z/OS System Programming: Volume 4, SG24-6984-00
ABCs of z/OS System Programming: Volume 5, SG24-6985-02
ABCs of z/OS System Programming Volume 6, SG24-6986-00
ABCs of z/OS System Programming Volume 7, SG24-6987-01
ABCs of z/OS System Programming Volume 8, SG24-6988-01
ABCs of z/OS System Programming: Volume 9, SG24-6989-05
ABCs of z/OS System Programming Volume 10, SG24-6990-04
ABCs of z/OS System Programming Volume 11, SG24-6327-0
ABCs of z/OS System Programming Volume 12, SG24-7621-00
ABCs of z/OS System Programming Volume 13, SG24-7717-01