MONMSG is a powerful tool, but sometimes even MONMSG needs a little extra help, and here's an example.

One of the great features of the System/38 was the Control Program Facility, or CPF. And one of the coolest things about CPF was the fact that any command you could enter from the command line could also be compiled in a program. This is different from interactively reading a script file, which is nice in its own way but isn't exactly the same thing. Scripts need more attention, especially in error handling; typically, an error causes some kind of alert to pop up on an operator's console, and then they have to decide how to deal with it. Compiled CL, on the other hand, not only understood errors but provided a very powerful tool to handle them, the MONMSG command.

OCL to CL: Losing a Letter, Gaining a World of Functionality

Running a CL program is just the best of all worlds. It allows you to cleanly separate your environmental issues (things like library lists and output queues) from your business logic. This practice allows business programmers to focus on the business issues and not worry about operations. This was really important during the first heyday of the midrange computer back in the late '70s and early '80s, when service bureaus were one of the primary users of midrange systems. As a service bureau, you could write one application and then effectively lease it to multiple clients by simply changing the data files. Midrange computers made this relatively simple, but originally it required scripts. The earliest were OCL scripts, and OCL statements were not exactly pretty. If you recognize the following statement, you might be an old System/36 programmer:

// IFF ?L'99,1'?/Y INI001

// IF DATAF1-?WS?IVWORK DELETE ?WS?IVWORK,F1

// BLDFILE ?WS?IVWORK,D,R,1000,120,,,,,DFILE

Yeah, I bet that brings back memories! Or maybe nightmares; if so, I apologize. But the point is that those commands are not compiled; they are read by an interpreter and parsed and executed on the fly. Typos aren't caught, and changes are fraught with peril. The next step in the evolution of the IBM midrange was the ability to take all those commands and then compile them as a program that, like any other program, could be debugged and stepped through, with variables and conditional code and everything. Today's CL has almost all the trappings of a modern compiled language, including extensive support of structured code. But at its heart, CL is still an operations language.

MONMSG: Handling Those Pesky Exceptions

And that's no more apparent than in how CL handles error messages. CL has a special opcode called MONMSG. MONMSG is so cool that it has two distinct operating modes.

One mode is when a MONMSG is placed after another command. If you put a MONMSG directly after a command, it can check for any errors and execute more commands. One of the great features of CL is that you can direct output of commands to database files and then access those files. A simple case is to process all the members in a file. The DSPFD command allows you to create a list of members, but what if the file doesn't exist? Well, if you don't have any MONMSG, the program will generate a CPF3012 exception (the CPF prefix should be familiar), the job will halt and go into MSGW state, and the operator will see a message in the QSYSOPR message queue. Now if this is a fatal error, you may want that to occur. But let's say that this is a situation where the file may not exist, and if it doesn't, you just want to continue. You can put a MONMSG CPF3012 after the command, and the message will be ignored and the job will continue on. You might want to let someone know, so you could put in the body of the MONMSG command a SNDUSRMSG to alert them:

DSPFD ARDATA *MBRLIST OUTPUT(*OUTFILE) OUTFILE(ARMBRS)

MONMSG CPF3012 EXEC(SNDUSRMSG 'NO MBRS IN ARDATA' JOE)

The second mode is invoked when you define MONMSG as the first executable instruction in your CL program. At that point, the MONMSG becomes generic to all commands in the program, and if any commands generate an error, the MONMSG will attempt to process it. I know I'm not telling you anything new, but I'm laying the groundwork. In fact, there are many more cool things about MONMSG, but that's really not what we're going after here. I want to do a deep dive into a very specific situation.

The situation is simple: some commands give you very specific error messages, and some commands are much more generic. The DSPFD command, as an example, can report over 20 different CPF messages. Other commands are more generic. The CALL command, for instance, returns only a handful. How can that be? Are there that many more errors that can occur in DSPFD? Not really. Instead, what happens with the call command is that many of the errors are reported as a diagnostic prior to the final exception message. If you do a CALL to a program that doesn't exist, you get two messages: a CPD0170, which says that the program is not found, followed by the very generic CPF0001 "Error in command" message. If the library you attempt to call from doesn't exist, you get a CPD0028 error, again followed by the CPF0001. This has pros and cons; it means you can simply monitor for the CPF0001 command and you'll get notified regardless of the underlying error. For a CALL command, that's probably the best solution because no matter why you couldn't call the program, the fact that you couldn't is probably a fatal error. But sometimes that's not the case.

ADDDIRE, CHGDIRE, CPF9082, and CPF9083

I recently had to write some code that would add directory entries to the System Distribution Directory. I wanted to run through a file, add the directory entry if it didn't exist, change it if it did exist, and report any errors that occurred. I also wanted to specifically report cases in which either the user profile didn't exist or the user was already enrolled but not with the correct address (there's a long backstory on the second situation; the short version is that these were primarily users that had been added long ago).

So like I would normally do, I started executing the command from the command line to determine the errors that could occur so that I could write MONMSG statements in my CL program. This looked to be very easy, until I realized something. Any failure in ADDDIRE returned a CPF9082 message that simply said directory entry not added. Similarly, CHGDIRE always returned CPF9083. What made this particularly difficult is that there was no easy command to check for an existing directory entry, so I had to attempt the ADDDIRE, and then, if I got an error saying the entry existed, go on to do a CHGDIRE. This could get ugly!

Enter the RCVMSG command. RCVMSG allows you to go back into the joblog and get previous messages. In this case, the immediately previous error message would give me detail on which error occurred. CPD9893 says the user and address is already in the directory (so go to the change). CPD9891 tells me the user profile is already enrolled, but under a different address. CPF2204 indicates the user profile isn't valid. So with a little work I can return a meaningful error code to the caller.

Figure 1: This is the code to add or update a directory entry.

Now this particular code may not be the most intuitive and straightforward, but it does a good job of illustrating all the features of MONMSG. First, my code at the top defines generic exception monitors. If CPF9082 occurs, this is an ADDDIRE error, and I need to go get the previous message to determine what to do. CPF9083 is a CHGDIRE error, and I want to do the same thing. Any other error goes to OTHERERROR and returns a generic error message (this normally occurs only when the user profile is more than eight characters long; directory entry user names must be no more than eight characters).

The magic then is in the GETDIAG section. It goes out and gets the previous message, which is the one that really identifies the error. If it's CPD8983, then it means this really was an ADDDIRE and that the entry already exists, so go attempt to change it. CPD8981 and CPF2204 set specific error codes. If a specific error code is set, the program returns it. Otherwise, the code drops through to the OTHERERROR section to return the generic error message.

I think this really shows off the capabilities of the MONMSG. I hope it helps you take a look at your CL programs and really think about how best to handle error conditions.