The Display Job Log (DSPJOBLOG) command lacks a few essentials for diagnosing problems in long-running interactive jobs; it needs a find function as well as the ability to filter messages by severity level. This article examines Scan Job Log (SCNJOBLOG), a new utility that provides both of those functions.

The job log is probably the first place you go when troubleshooting a problem with an interactive job. But when you ask a user how an error was found, you will likely be rewarded with a blank stare or some sort of incoherent mumbling, and that’s understandable. After all, this is your world, not theirs.

Troubleshooting is unpleasant and difficult for programmers, but an amply filled toolbox can make it easier. The utility described in this article is designed to help you diagnose problems by making job logs easier to deal with.

Out with the Old

If the job that ended in an error is no longer active, you can use one of several ways to locate the spooled output files for the job and then display the file QPJOBLOG. The Display Spooled File (DSPSPLF) command is not overly helpful in analyzing a job log but does have a find capability, which comes in handy when looking for the cause of an error.

On the other hand, if the interactive job is still active, you must use the Display Job Log (DSPJOBLOG) command to view the job log. However, we personally find DSPJOBLOG woefully inadequate when trying to analyze long-running interactive jobs; the command lacks any kind of rudimentary find capability and other features that would be useful in analyzing a job log for a long-running job.

In with the New

What you really want is to be able to filter out nonessential informational messages quickly from a largely unintelligible job log. You want to look only at error messages in the job log that are greater than a given severity level. You could then roll quickly through the “more interesting” messages until you find one pertinent to the problem. You should then be able to turn off the filter and read the complete job log, starting at that point. We also thought it would be nice to have one command to locate the job log with the same consistent interface, regardless of whether the job is active.

Those needs led us to write Scan Job Log (SCNJOBLOG). Figure 1 shows the output of SCNJOBLOG; the command entry panel for SCNJOBLOG is shown in Figure
2. When running SCNJOBLOG, you supply the job name whose job log you want to scan. This parameter defaults to *, which is the IBM default that instructs the command in question to use the current job. You can enter the name of any interactive or batch job; if your job log file name has been overridden to something other than QPJOBLOG, you can enter the actual name in the optional parameter, FILENAME.

Our initial idea was to make this utility work like DSPSPLF. However, extracting different types of information from a single control field required too much code, so we separated the control field into several fields, as you can see in Figure 1. The control fields are designed to provide most of the same functions as DSPSPLF’s control fields.

You input the control code in the field labeled Control and press Enter. For instance, you can go to the bottom of the job log by entering a B and return to the top by entering a T. Window left or right by using the code W in conjunction with a positive or negative number indicating the increment you desire. To move to the right, enter a plus (+) in the Direction field, or enter a minus (-) to move to the left. If you are trying just to reposition the screen without keying W, the Increment field indicates the number of lines to move up or down. If you leave the Direction field blank and enter only an increment value, you will go directly to that line (as opposed to advancing that number of lines from the current position).

The Find field allows you to scan the job log for a particular phrase. The From field allows you to designate that each line is searched beginning at a particular column. The find function works a little differently than the DSPSPLF command’s find function in that the subfile is built with the complete message containing the search field. This is the case even if that message spans multiple lines, so you end up with a subfile containing all messages that contain the search field. With DSPSPLF, the find function stops at each occurrence of the search field.

If you enter a value in the Severity field, only messages that have a severity level equal to or greater than that value are displayed. This allows you to roll quickly through a long job log, viewing only important messages. When you reach the section that is pertinent to your problem, zero out the Severity field to see all messages starting from that point.

How It Works

The code for SCNJOBLOG is available for downloading from Midrange Computing’s Web site at www.midrangecomputing.com/mc/99/06, but here’s a general look at how the command works.

SCNJOBLOG consists of four source members:
• Command SCNJOBLOG
• CL program SRC620CL
• RPG IV program SRC620RG
• Display file SRC620DS The CL program first checks to see if the job log has been written to a spool file. If it hasn’t, the CL program runs DPSJOBLOG to create a spooled file.

The spooled job log is then copied to a temporary file that the SRC620RG program can read. The program builds a subfile, one page at a time, by reading the spooled file records. Each record is written to the subfile unless the filtering or find functions are requested.

Being able to filter the subfile by message severity causes a problem from a technical point of view. Because message severity is not on every line in the job log, you need to be able to recognize when a message begins as well as when it ends. We noticed that a couple of fields are never blank on a primary message line but always blank on

Features

subsequent lines, allowing us to control the writing of the complete message to the subfile when the user is filtering by severity.

The find capability creates yet another challenge from a programmer’s perspective. If any line of the message contains the search phrase, you want to write the complete message. However, it is possible to read a record, ignore it because it does not contain the search phrase, and then read the next few lines of the message that does contain the search phrase. In this case, you need to go back to the top of the message and begin writing it to the subfile. To account for this situation, every time you recognize the beginning of a primary message line, save the relative record number. Then, if you must, you can reset the pointer to the beginning of the message and call the WRITEMSG subroutine to read the complete message and write it to the subfile. This process involves a little more I/O than you might like, but it works.

The subfile displays the beginning of the job log. If the user enters a control request, execute the EXTRACTCNT subroutine to analyze the request. This subroutine repositions the pointers to the database file or offsets the data by the required number of characters.

Reality Bytes

Th is c omma nd p rovi des more cap abil itie s an d a more con sist ent user int erfa ce fo r vi ewin g jo b lo gs. Even if you writ e pe rfec t co de t hat neve r co ntai ns b ugs (lik e us , fo r in stan ce), you r us ers will lik ely stil l fi nd s ome unin tend ed “ feat ure” in a pr ogra m th at n eces sita tes view ing a jo b lo g. N onet hele ss, this too l sh ould mak e it a l ittl e ea sier to fin d ou t wh at t hey did in t heir wor ld t hat wrea ked havo c in you rs.

Figure 1: Here is an example of the SCNJOBLOG command output.

<>
<>
<>

<>
<>
<>

Figure 2: These are the parameters for SCNJOBLOG.

Also Read

Practical Middleware: Architecting for the Future

Practical Middleware: Starting the Journey

IBM i 7.2: The Carrot Versus the Stick