Admin Alert: Three Common Mistakes in CL Administration
January 14, 2004 Joe Hertvik
With a mature operating system like OS/400, there are plenty of subtle tricks you must understand in order to ensure that you are administering your system correctly. This week’s “Admin Alert” looks at three common OS/400 administration mistakes and explains how to avoid them and keep your shop running smoothly.
MISTAKE 1: NOT GIVING A SUBSYSTEM ENOUGH TIME TO END
This is a common problem in CL programs that restart a subsystem by issuing an end subsystem command, followed by a call to restart the subsystem. A simple example is the following piece of CL code used to perform maintenance for a third-party software package. This code ends a subsystem, backs up a critical file that is usually locked by the subsystem, clears the file, and then it restarts the subsystem:
ENDSBS SBS(SUB1)
MONMSG MSGID(CPF0000)
CPYF FROMFILE(LIB/CRITICAL) +
TOFILE(LIB/CRITICALBK) MBROPT(*REPLACE) +
CRTFILE(*YES)
MONMSG MSGID(CPF0000)
CLRPFM FILE(LIB/CRITICAL)
STRSBS SBSD(SUB1)
MONMSG MSGID(CPF0000)
The problem with this code is that the subsystem doesn’t always restart when the code runs. That’s because the success of this code depends on how quickly the End Subsystem (ENDSBS) command executes. If the command completes quickly (that is, before the Copy File (CPYF) completes and the Start Subsystem (STRSB) commands runs), the process is successful. But if the STRSBS command runs before the subsystem ends, you’ll have problems. You won’t be able to clear the file, because it’s still locked, and you also won’t be able to restart the subsystem while it’s ending.
Curing this problem is easy. Simply estimate how long the subsystem generally takes to end, then insert a Delay Job (DLYJOB) command for that amount of time into your code. The DLYJOB should be inserted immediately after the End Subsystem (ENDSBS) command runs, so processing is delayed until the subsystem is down. DLYJOB can suspend a job for a specified number of seconds, or it can suspend the job until a specified clock time occurs. By using DLYJOB, you can temporarily pause the job so that the ENDSBS command can finish its work.
To modify this code to include a DLYJOB command that pauses the job for five minutes while the subsystem ends, simply change the code to the following:
ENDSBS SBS(SUB1)
MONMSG MSGID(CPF0000)
DLYJOB DLY(300)
CPYF FROMFILE(LIB/CRITICAL) +
TOFILE(LIB/CRITICALBK) MBROPT(*REPLACE) +
CRTFILE(*YES)
MONMSG MSGID(CPF0000)
CLRPFM FILE(LIB/CRITICAL)
STRSBS SBSD(SUB1)
MONMSG MSGID(CPF0000)
Note that the job delay in DLYJOB can be counted in seconds, as shown here with the Job Delay Time (DLY) parameter, where 300 seconds equals five minutes, or you can delay the job until a particular job resumption time by using the Resume Job Time (RSMTIME) parameter.
Unless there’s an error with your subsystem ending, this approach generally solves any problem with subsystems trying to restart before they’ve completed ended. It’s also worth noting that DLYJOB commands can help when an action must be completed before another starts.
MISTAKE 2: INITIALIZING A TAPE THE LONG WAY
When you use the Initialize Tape (INZTAP) command to initialize your tapes, there is a parameter called Clear (CLEAR), which specifies whether all the prior labels and data on the tape should be deleted from the tape when it’s initialized. CLEAR has two possible values: *YES, which deletes all data on the tape, and *NO, which leaves the data on the tape.
Unless there is a security concern in leaving old data on your tapes, you can usually initialize tapes by using the CLEAR(*NO) parameter, as follows:
INZTAP DEV(TAPXX) NEWOWNID(NEWOWN) CLEAR(*NO)
If you specify CLEAR(*YES), the initialize process will take much longer, because INZTAP will delete all existing data from the tape after the initialization process. The funny thing about this parameter is that existing data is generally not accessible after the volume has been initialized, so whenever a cleared tape isn’t an overriding security concern, you’re usually safe by using the CLEAR(*NO) parameter.
MISTAKE 3: USING QTEMP THE RIGHT WAY
Traditionally, system storage is one of the more expensive components of an iSeries box, so it makes sense to avoid filling up expensive DASD with work files. That’s where library QTEMP comes in. While there are a few different rules for using QTEMP in a client/server environment, there is a separate QTEMP library created for and assigned to each green-screen job when it starts. Each job has full reign over its individual QTEMP library; QTEMP is treated like any other library as far as the job is concerned, and the QTEMP library and all of its contents are deleted when the job is ended.
With these features, this makes QTEMP a great place to put work files for a job. By using QTEMP for work files, files can be created and filled on the fly and can be used to process permanent data, then the work files can automatically be deleted when the job ends. This saves DASD, and as a bonus, you don’t have to worry about clearing out work files for the next time the job runs.
I recently used this recently in a procedure to determine which files needed to be reorganized, which included the following piece of code:
PGM
DSPFD FILE(*ALL/*ALL) TYPE(*MBRLIST) +
OUTPUT(*OUTFILE) FILEATR(*PF) +
OUTFILE(QTEMP/REORGMAP1)
CPYF FROMFILE(QTEMP/REORGMAP1) +
TOFILE(LIBNAME/REORGMAP) +
MBROPT(*REPLACE) FMTOPT(*MAP *DROP)
ENDPGM
In this case, the REORGMAP1 file is created as a temporary work file in the Display File Description (DSPFD) command, and the file will be deleted when the job running this program completes. By using QTEMP, this program only allocates system storage for its work file as the storage is needed and then gives the storage back to OS/400 when completed.
In general, QTEMP is a great place for any temporary files or objects that you don’t want to leave sitting around cluttering up your OS/400 DASD.
There are two downsides to using QTEMP, however. First, since QTEMP is generally assigned only to one job, you cannot share objects with other OS/400 jobs that may need access to your temporary files.
Second, you have to be careful where you place QTEMP in your library list. When QTEMP resides higher in your user’s library list, a signed-on user can possibly use QTEMP to create a copy of a production file and then manipulate or falsify its data for posting to other live files or to produce official-looking falsified documents. If QTEMP is listed high enough in the library list, the user may be able to override the production file with its doppelganger in QTEMP and cause system mischief. For system security purposes, you may want to include QTEMP lower in the library list.
Knowledge is power, and the better you understand the intricacies of OS/400, the better equipped you’ll be to manipulate it in order to prevent others from taking advantage of a mistake.
FOLLOW-UP ON ENDJOBABN AND APPLYING PTF’S
After the column on whether the End Job Abnormal (ENDJOBABN) command affects PTF applications, I received an e-mail from IBM confirming that APAR SA54989 (which dealt with this issue for OS/400 V3RX) still applies to OS/400 V5R2. This means that delayed PTFs will be applied after an abnormal termination if the only reason for the abnormal termination is that the system ended a job abnormally by using ENDJOBABN. The author of the e-mail confirmed that he received this answer from the Rochester support group but that he didn’t test PTF application after an abnormal termination. So it looks like our question was answered, and using ENDJOBABN will not affect how you apply PTFs on your next IPL.
