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?

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.