Messages, QSYSOPR and the job log

On other systems you go looking for logs in a directory. Here messages are objects that travel between jobs, and land in message queues: every job has one, every user has one, and the system has a few that concern everybody.

The advantage is that every message knows where it came from: which program, which statement, which job. The price is having to know which queue to look in.

The queues that matter

• QSYSOPR — the system operator's queue. What the system wants whoever runs the machine to know arrives here: devices in error, requests waiting for an answer, subsystem notices.
• QSYSMSG — the queue for serious messages. It does not exist until you create it, and that is one of the few things worth doing on any system on day one.
• The user's queue — one per profile, receiving messages addressed to that person.
• The job's queue — the individual job's record, that is, the job log.

DSPMSG MSGQ(QSYSOPR)
WRKMSGQ

CRTMSGQ MSGQ(QSYS/QSYSMSG) TEXT('Serious system messages')

Messages waiting for an answer

Some messages are inquiries: the job that sent one stops until somebody answers. These are what hold the night-time close for eight hours, with nobody the next morning understanding why.

They show up in DSPMSG and are answered right on the line. You recognise them by their list of expected replies: C to cancel, R to retry, I to ignore, G to go on.

The job log

Every job writes its own record. While the job is alive:

DSPJOBLOG JOB(123456/JSMITH/CLOSE)

Once the job has ended, the record becomes a spooled file — QPJOBLOG — in the job's output queue. That is why job logs are found in WRKSPLF and not in a directory: they are printouts.

Reading one in SQL, which from release 7.3 saves scrolling through hundreds of lines by hand:

SELECT SPOOLED_DATA
  FROM TABLE(SYSTOOLS.SPOOLED_FILE_DATA(
       JOB_NAME          => '123456/JSMITH/CLOSE',
       SPOOLED_FILE_NAME => 'QPJOBLOG'))
 WHERE SPOOLED_DATA LIKE '%CPF%'

How much it writes

The LOG parameter of the job description decides level and detail. A value often met is LOG(4 0 *SECLVL): record everything, second-level explanation included.

A job that ends cleanly, by default, often leaves no job log at all: LOGOUTPUT(*PND) holds it pending and never produces it. This is not a fault — it is why sometimes there is no record of a job that went fine.

Reading an error

Every message has a code — CPF9801, CPD0032, MCH3601 — and the code has a two-level explanation: the short text, and the second level giving cause and possible recovery. In DSPJOBLOG put the cursor on the line and press F1.

The prefix says where the message came from: CPF from the operating system, CPD from command diagnosis, MCH from the machine level, SQL from the database, RNQ and RNX from RPG.