Back in week 50/2003 I wrote about how you issue an ISPF message from a REXX. Some of the messages that I have issued was the result of an ISF service returning a return code not equal to 0. Sometimes I have used a lot of time on recreating the same messages as those returned by ISPF.

Now I have found a way around this tedious task. I have discovered that ISPF maintains a variable called ZERRMSG. This variable contains the name of a message that ISPF has built as a result of a bad return code from ISPF. Now imagine that you have built a REXX that EDITs the dataset that the caller of the REXX supplies in a parameter like TSO %MYEDIT A.B.C where A.B.C is the dataset name. Before this tip I used a lot of code on validating the dataset name and on validating if the dataset existed or not, but now the same REXX look like this:

/* REXX: MYEDIT */
ARG DSNAME
ADDRESS ISPEXEC "CONTROL ERRORS RETURN"
ADDRESS ISPEXEC "EDIT DATASET('"DSNAME"')"
IF ZERRMSG ^= ''
THEN
  ADDRESS ISPEXEC "SETMSG MSG("ZERRMSG")"
ADDRESS ISPEXEC "CONTROL ERRORS CANCEL"
EXIT

This REXX will issue exactly the same messages as the ISPF editor if you use an invalid dataset name or a non-existing dataset name as a parameter. It will also issue the correct messages when the EDIT session terminates; as whether you saved the data or not. If you want to use ZERRMSG from a COBOL or PL/I program you must remember to VDEFINE the ZERRMSG variable.

The best thing about ZERRMSG is that it is set by all ISPF services. Pay attention to the ISPF service CONTROL ERRORS RETURN that gives your program full control after any ISPF service call no matter what the return code is. It is not well defined when ISPF shifts back to normal processing of errors from ISPF services. Therefore I issue a CONTROL ERRORS CANCEL at the end of the REXX. Normal processing means that if an ISPF service gives a return code greater than 8 then ISPF terminates further processing of your program after showing the user a panel where ISPF tries to explain the situation.

The use of CONTROL ERRORS RETURN will not help you if the ISPF service call is wrong. If I had written EDIT DATASUT... then ISPF would interrupt my program execution and ignore CONTROL ERRORS RETURN. Because of this detail I check the value of ZERRMSG for blanks before calling SETMSG. I have discovered that some ISPF services does weird things that sets ZERRMSG to blanks which causes SETMSG to fail.