There are times when you can't code around a system message, but at least with this technique you don't have to sit around and wait for it.

Can't or won't?

OK, chances are that if you try hard enough you can manage to code around nearly any system message. But there are times when the amount of work required simply isn't practical. I'll give you a real-world example that I've run across on many occasions over the years and show you a relatively easy way to get around the problem, as well as an additional trick that can help in some stricter environments.

The Problem Is Simple: Too Many Objects!

Whenever I start working at a new shop, one of the first things I need to do is analyze the environment. Sometimes, the shop will have a robust change management system in place that is strictly adhered to, with an equally well-maintained object analysis. And sometimes it won't. In the latter case, my analysis usually involves some simple steps, such as getting a list of all objects and all source on the system and then comparing the two.

Each shop is slightly different, but generally speaking, they'll have several different environments (typically serving roles like development, QA, and production). I run things like DSPOBJD, DSPFD, and DSPPGMREF to output files, one for each environment. Then, in order to get a comprehensive view, I merge the results of those files into larger files. I know that I can also do a view over the files, but there are some drawbacks to that approach. In any case, what I end up having to do is to copy two files together, something like this:

CPYF ANZLIB/ENV1OBJ ANZLIB/ALLOBJ CRTFILE(*YES)

CPYF ANZLIB/ENV2OBJ ANZLIB/ALLOBJ MBROPT(*ADD)

CPYF ANZLIB/ENV3OBJ ANZLIB/ALLOBJ MBROPT(*ADD)

You'll note that I created three files—ENV1OBJ, ENV2OBJ, and ENV3OBJ—and I basically want to combine them with CPYF. As I noted earlier in the article, I could probably figure out a way to do this differently, but in the specific case I'm talking about, this is just the most straightforward answer.

The problem comes in when I do the copies. IBM creates files with a default maximum size of 190000 records (an initial size of 100000 and then 3 increments of 30000), and it's easy to exceed that size when displaying all the objects in a production system. So what ends up happening is simple: You get an error during the copy. It's the dreaded CPA3138 "Member at maximum size" error. It's relatively easy to deal with—you just hit "I" to ignore—but the problem is not answering the message; it's waiting for it to occur. Dumping an entire system's worth of information can take a long time, and you typically want to do it off hours anyway, so the message tends to come up when you're not signed on to the system.

The Solution

That's where the system reply list comes in handy. The system reply list allows me to create a default message response. The operating system will review every message that pops up, and if it's one that is being monitored by the reply list, then the OS will happily slap in that default response just as if I had keyed it in myself.

It's quite easy to do. Adding the message is as simple as executing the ADDRPYLE command:

ADDRPYLE SEQNBR(1001) MSGID(CPA3138) RPY(I)

The ADDRPYLE has a few other options; the most important of them configures the entry to check the message data before actually executing the reply. It would be really nice if you could configure it to check for a specific job name or user (for reasons I'll explain in a moment), but that's not available. Also note that all this does is add the message to the system reply list. In order for the reply list to affect a job, the job has to be configured to use it. That's done with one very simple command:

CHGJOB INQMSGRPY(*SYSRPYL)

That's all it takes. One little command and the CPYF will not be interrupted by those pesky maximum size messages (at least none that require my response).

The Problem with the Solution

When IBM calls it the "system reply list," they mean just that, because the reply list is scanned for every job in the system that has the reply list enabled. So this is sort of a big hammer: When I add the entry, it potentially changes how every job behaves. If my production jobs normally use the system reply list, then by adding this automatic response, I've basically made every file in the system a le, allowing them all to expand forever.

That may be fine in the case of my utility because I'm just copying the data from one file to another, but what happens if I get a runaway job that's in a loop adding records to a file? Well, depending on the program and the amount of disk on the system, at some point I'm going to get a really bad error message telling me I've run out of disk space. And that's a lot more inconvenient than answering a few “file full” messages.

How do I get around that? Since this particular reply list entry is one that probably shouldn't ever run entirely unattended, what I usually do is add the reply list entry only when I start the job and then remove it afterward. So rather than adding the entry some time as a one-time system configuration, I instead add it dynamically when the job starts. It isn't perfect by any means, but it does prevent me from forgetting and leaving it there, unless of course the program blows up. And adding a reply list dynamically can be tricky; since you can't have two reply list entries with the same sequence number, you have to dedicate one of your 9999 available sequence numbers to each dynamic reply, but given the rarity of this particular procedure, that shouldn't be too difficult to manage.

Speaking of management, if you do decide to add a permanent reply list entry, the command that adds it should be added to your OS configuration CL. If you don't have an OS configuration CL, you should. And that's a great topic for an upcoming article.