Kill Jobs Preparation
We can be in a situation with Degradation where we have identified a job that needs to be killed, but to do wo without some preparation, can cause other problems, the least of which we lack clues to help figure out how to prevent this from happening again.
What should we do to maximize productivity of this kind of problem solving?
HOLD / Prepare / KILL
While futzing with stuff, like adjusting what is in JOBQ, and making sure that a JOBLOG will be captured, we might want to stop the damage, without stopping the job.
We can put the problem job ON HOLD
Typically WRKACTJOB or WRKUSRJOB
Locate the problem job and put it on hold, so that it is not hogging the system while we do the preparation before killing it.
If you know the precise job identification you can also Bold textCHGJOB F4 it.
JOBQ
WRKUSRJOB F4 *ALL *JOBQ shows ups 100% of what is waiting to run from all JOBQ.
For most sites, a runaway hog job is a rarety, so no one pays attention to what is going on with the JOBQ until we have several hours worth of work wating in line behind the hung job. As soon as the runaway hog job is ended, the JOBQ will begin to process the traffic jam, but first we may wish to adjust the priorities of what is yet to run.
There may be jobs in JOBQ behind the hung one, that are dependent on the successful results of the failed job. We want to put them on hold, and perhaps move to a separate JOBQ.
Typically when some job is hung, that came from the JOBQ, there are a mountain of other jobs waiting in line to run behind it. Most are independent, but in some cases, the software expects this thing to run, then that thing, in a certain sequence, so before rearranging what is ro run in JOBQ a person needs to understand the application interrelationships, how long stuff typically takes to run, what is safe to run from alternate JOBQ, and your 400 capacity for multiple concurrent busy JOBQs active.
JOBLOG
Job Logs are desirable to gather clues when problem solving, but when stuff running normally, we not want the logs, because they eat disk space, and the process of writing the logs can slow down the system.
But now something has a problem for which we want a joblog captured.
