The S/36E on the AS/400 provides a terrific way to "dabble" in native CL commands while staying within the comfortable confines of S/36E OCL. It allows you to use most native CL commands from within your OCL procedures.

The problem is that if a native command fails, the system takes the default response to the OS/400 error message and returns control to the procedure as if nothing happened! Your OCL then goes merrily on its way thinking that the native command ran successfully when in actual fact it did not. When you try to use the MONMSG command to check for error conditions you find that this is one of those CL commands that doesn t work in OCL.

There is a solution, albeit not very well-documented. The S/36E provides a new system variable ?MSGID?. This is similar to a return code (?CD?) and can be used to check for error conditions in lieu of MONMSG.

To take advantage of the ?MSGID? substitution parameter, you must code it following the CL command you think may cause an error. If no error message is issued, ?MSGID? will be blank; if OS/400 issues an error message, ?MSGID? will have the seven-character message ID of the escape message, such as CPF1234.

For example, 2 shows an OCL procedure in the S/36E containing the RGZPFM native command, which may result in an error if the file is not found.

For example, Figure 2 shows an OCL procedure in the S/36E containing the RGZPFM native command, which may result in an error if the file is not found.

As we can see, the procedure will take care of the problem should the file not be found. Although this particular case could have been handled by the // IF DATAF1 procedure control expression, the example clearly demonstrates the ?MSGID? technique.

- Rich Loeber

TechTalk: Not Quite an S/36E MONMSG

Figure 2 S/36E error trapping

 Figure 2: S/36E Error Trapping // RGZPFM FILE(?1?) MBR(*FIRST) // IF ?MSGID?= GOTO OK // ** Procedure aborted - File ?1? not found // CANCEL // TAG OK // LOAD PGM1 // FILE NAME-?1?,DISP-OLD // RUN