Admin Alert: When a Job Doesn't End

by Joe Hertvik

OS/400 is such a nicely constructed operating system that you don't have to worry much about ending errant jobs. This week's "Admin Alert" takes a look at two ways to end an OS/400 job: the nice way, by using an End Job (ENDJOB) command, and the nasty way, by using an End Job Abnormal (ENDJOBABN) command. I'll also cover some reader e-mail.

In most situations, a job will cancel quite nicely by issuing an ENDJOB command against itself from the green screen, like this:

ENDJOB JOB(999999/USER/JOBNAME)

ENDJOB then terminates the offending job in a controlled manner, meaning that OS/400 will wait 30 seconds for the job to end on its own (a controlled ending) before the operating system terminates it. 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). If, for example, I wanted to tell OS/400 to wait five minutes before ending a troublesome job, I could enter the ENDJOB command as follows:

ENDJOB JOB(999999/USER/JOBNAME) DELAY(300)

Since the DELAY parameter is measured in seconds, this tells OS/400 to wait five minutes before ending the job. Also note that the How to end parameter (OPTION) must be set to a controlled ending (*CNTRLD) in order to use the DELAY parameter. *CNTRLD is the default value for OPTION, so the actual statement that OS/400 is running is the following:

ENDJOB JOB(999999/USER/JOBNAME) OPTION(*CNTRLD) DELAY(300)

To end the job immediately from my system console, I could change the How to end parameter (OPTION) to *IMMED, which tells OS/400 to immediately attempt to end the job. In this case, the ENDJOB command would look like this:

ENDJOB JOB(999999/USER/JOBNAME) OPTION(*IMMED)

And OS/400 would attempt to end the job immediately. Occasionally, however, a job will refuse to end through an ENDJOB command. It doesn't happen very often, but when you have a mule-headed job that simply will not end with ENDJOB, you need something stronger, like the End Job Abnormal (ENDJOBABN) command:

ENDJOBABN JOB(999999/USER/JOBNAME)

ENDJOBABN has been known to take down jobs that are too stubborn for ENDJOB. But it has a few limitations that you need to be aware of. Specifically, the following things affect ENDJOBABN use:

• ENDJOBABN cannot be run against a job before you've attempted to end the job through the ENDJOB command, with *IMMED specified in the "how to end" parameter. OS/400 is also hard-coded to ignore an ENDJOBABN statement until 10 minutes have passed since you ran an ENDJOB *IMMED command on the same job. So not only do you have to run ENDJOB for a problem job before using ENDJOBABN, you also have to give ENDJOB time to work.
  
  
• ENDJOBABN is shipped with *PUBLIC *EXCLUDE authority. And to run ENDJOBABN, you need job control (*JOBCTL) authority in your user profile.
  
  
• ENDJOBABN can be run against a job only once. Additional ENDJOBABN commands can't be run.

So if you keep these restrictions in mind, ENDJOBABN can be a powerful addition to your OS/400 system administrator toolkit, and be the thing you reach for when you can't end a job any other way.

E-Mail from Readers

To end this week's Alert, I wanted to follow up on a few e-mails I received from loyal readers that both challenge and confound me as I write this humble column.

In "Hidden Secrets of the SBMJOB Command," I mentioned that if you're submitting a server job using the Submit Job (SBMJOB) command, you may want to submit it to the QSYS/QSYSNOMAX job queue. QSYSNOMAX is attractive because it feeds into the QSYSWRK subsystem, which can run an unlimited number of jobs at once. As reader Thomas Kupchinsky pointed out, however, one should be cautious when executing multiple jobs from the same job queue, because one job may depend on the completion of another.

And this is a good point because running interrelated batch jobs out of sequence can easily corrupt your data and cause a number of problems in your system.

The key here is to use your job queues and subsystems wisely. For production batch jobs where one job is dependent on the completion of another, your jobs should always be submitted to a job queue that serves a single-threaded subsystem (that is, a subsystem that can only run one batch job at a time).

For batch jobs that are unrelated, like queries and client/server-type jobs, job queues that feed several jobs into the same subsystem at the same time will serve quite nicely, and you might want to set up your own batch subsystem for this purpose. But for server jobs, where the vast majority of the job's system time is spent waiting for an event that it must service, you might do well to submit those jobs into the multiple-job QSYSWRK subsystem. IBM uses QSYSWRK for running TCP/IP server jobs, and it's easy enough to plug into this architecture by submitting your own server jobs to the QSYS/QSYSNOMAX job queue. In my shop, I use QSYSWRK to run jobs that e-mail OS/400 reports, perform data collection, periodically produce printer output, and run server jobs that are provided with third-party software. Unlike interrelated batch production jobs, server jobs often function better in a multiple job subsystem.

Always use the right subsystem for the right job.

Questions from the "Admin Alert" Mailbag

From time to time, I receive questions from readers but don't immediately have the answers. Muhammed has asked the following question, which I publish here in the hope that one of our readers can answer it:

I've discovered a drawback to using the Submit Job (SBMJOB) command, described in "Hidden Secrets of the SBMJOB Command." I can't seem to submit a job that passes numeric parameters in the Submit Job command. A typical example involves these steps: interactively call a CL program with a numeric parameter; the program runs correctly; submit the same job to batch with SBMJOB, and the submit job command will fail.

If you know how to solve this problem, please send me an e-mail at jhertvik@itjungle.com, and I'll pass it on to Muhammed. Useful solutions may also be used in future "Admin Alert" columns.

Sponsored By BYTWARE

Rachel has multiple systems and partitions running WebSphere, Domino, and more. Sound like a management nightmare? Normally it could be, but with MessengerConsole it's so easy! Rachel can see events from all systems and partitions on a single screen. Now she's saving thousands by managing multiple systems and partitions with fewer resources. Get the Message. Get MessengerConsole. www.bytware.com/products/mconsole.html