The Four Hundred--Admin Alert: Reader Feedback on How ENDJOBABN Affects PTF Application

In last week's Admin Alert, I discussed some different ways to abnormally end an OS/400 job, including using different variations on the End Job (ENDJOB) and the End Job Abnormal (ENDJOBABN) commands. After writing that column, I received a few interesting e-mails highlighting some different features of ENDJOB and ENDJOBABN that I hadn't discussed. This week, let's review the e-mail feedback and see what we can learn.

Reader Howard Kapnic tipped me off to an obscure but important association between the use of the ENDJOBABN command and PTF application. After double-checking Howard's information with IBM, I found out that using ENDJOBABN can prevent your system from applying PTFs on an unattended IPL. Here's how it works.

Many PTFs are not temporarily applied until your system is IPLed (powered down and powered back up again). In fact, when you load PTFs, OS/400 applies whatever fixes can be applied at load time and then marks the rest of the new PTFs to be applied at IPL (much the same way that some Microsoft's Windows patches and some third party programs aren't fully loaded until you reboot the system).

However, in order to apply PTFs at IPL time, OS/400 requires that the system must have ended normally when it was last powered down. Obviously, IBM doesn't want you to apply PTFs after the system ended abnormally because system objects could be damaged. The mechanism OS/400 uses at IPL to determine whether the last system power down was successful is a system value called the previous end of system indicator, QABNORMSW. You can look at this value by running the Display System Value (DSPSYSVAL) command from a green screen, as follows:

QABNORMSW is set to either '0' (Normal) or '1' (Abnormal). OS/400 sets this value as the machine is powered down, and it is not possible to reset this value manually. QABNORMSW is normally set to '0' but OS/400 will set it to '1' in two situations:

So if you end any job by using ENDJOBABN, OS/400 will mark your previous end of system status as abnormal the next time the machine is IPLed. And if you also loaded PTFs for unattended application during the next IPL, those PTFs will not be loaded as the machine comes up. You will have to perform a second power down-IPL sequence where you system ends normally before the PTFs will be applied at IPL. The hassle here is that in situations where you only have a limited amount of time to IPL your machine for PTF application, the second "clean" IPL will add extra time to what could be a very tight timetable.

The use of the ENDJOBABN command can affect your ability to load PTFs in a timely manner. Be aware of this and use ENDJOBABN sparingly if you plan to apply PTFs (if you're not applying PTFs on the next IPL, using ENDJOBABN shouldn't matter). If you're forced to use ENDJOBABN before applying PTFs, understand that you'll need to allow extra time for a second IPL when you re-IPL your machine.

Reader John Davis wrote in to correct a mistake in division I mentioned in the ENDJOB/ENDJOBABN article. See if you can spot my math error in the following paragraph I wrote about increasing the amount of time that ENDJOB command takes before it terminates a job.

"If you want to increase the amount of time that OS/400 waits before termination, adjust ENDJOB's Delay Time parameter (DELAY) upward, to a maximum delay of 999999 seconds (which is roughly 116.65 minutes, or just under two hours)."

To which John noted the following regarding my calculation for converting seconds into minutes:

When you prompt the ENDJOB "Delay Time, if *CNTRLD" parameter for help text, you'll see that it]reveals that the maximum delay-time is, in fact, 999,999 seconds. But, the article says that 999,999 seconds equates to just under two hours. Some quick calculations on my desktop calculator show 999,999 seconds to be equivalent to 16,666.65 minutes, or 277.7775 hours, or 1.65+ weeks. It looks like a couple of decimal points were dropped somewhere on the way to the press.

I don't expect anyone would ever use the maximum setting. But someone who might want to use a large number that is substantially less than 999,999, possibly motivated by the calculations in the article, might believe that they would be setting the ending of the job for something substantially less than two hours but more than just a few minutes.

To which I plead guilty. It wasn't an error on the way to press, it was an error in my math skills and readers should take note of this correction. If you think my math was bad here, you should see what I can do to a checkbook. ;-)

Last week, I posted an Admin Alert question to the readership asking for possible solutions to the problem of passing numeric parameters in the OS/400 Submit Job command (SBMJOB). I received a number of responses to this query, and I thank everyone who wrote in with a suggestion. I'll be passing on your suggestions to the reader who brought up the problem, and these answers will become the focus of a future Admin Alert column.