Difference between revisions of "Kill Jobs Preparation"
m |
|||
| (11 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | We can be in a situation with [[Degradation]] where we have identified a job that needs to be killed, but to do | + | [[Category:Administration]] |
| + | [[Category:Trouble Shooting]] | ||
| + | We can be in a situation with [[Degradation]] where we have identified a job that needs to be killed, but to do so 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? | 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, until the preparation is completed. | ||
| + | |||
| + | 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 '''CHGJOB''' F4 it. | ||
== JOBQ == | == 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 == | == 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. | ||
| + | |||
| + | * If it is from JOBQ, we want to '''CHGJOB''' so that '''LOG(4 0 *SECLVL)''' | ||
| + | * If it is an interactive job, we want the user to use '''SIGNOFF *LIST''' | ||
| + | |||
| + | If after we end the job, it is still hung like 10 wall clock minutes later, we may want to force an end with '''ENDJOBABN''' ''End Job Abnormally''. | ||
== Power Users Key Elements == | == Power Users Key Elements == | ||
| + | |||
| + | Typically IT personnel are not familiar with the workings of all the applications of co-workers. Power Users are experienced people in various departments who know some applicaiton backwards and forwards, and are people to whom the newer workers look to for help. IT can give them greater Computer Security Access, so that they can use their growing experience to be people in the middle between the users who need help, and IT. | ||
| + | |||
| + | IT can show Power Users: | ||
| + | * How to adjust sequence in which stuff will print on printers, so that humongous reports do not delay delivery of smaller reports; | ||
| + | * How to arrange that all reports from one person are on hold, to be released at a particular time, so they are all together, not intermingled with everyone else's reports. | ||
| + | * How to identify individual tasks and what they are doing. | ||
| + | * How to rearange sequence of stuff in JOBQ without messing up inter-dependencies. | ||
| + | * Get in habit of using F4 key instead of ENTER key. | ||
Latest revision as of 19:40, 27 June 2005
We can be in a situation with Degradation where we have identified a job that needs to be killed, but to do so 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, until the preparation is completed.
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 CHGJOB 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.
- If it is from JOBQ, we want to CHGJOB so that LOG(4 0 *SECLVL)
- If it is an interactive job, we want the user to use SIGNOFF *LIST
If after we end the job, it is still hung like 10 wall clock minutes later, we may want to force an end with ENDJOBABN End Job Abnormally.
Power Users Key Elements
Typically IT personnel are not familiar with the workings of all the applications of co-workers. Power Users are experienced people in various departments who know some applicaiton backwards and forwards, and are people to whom the newer workers look to for help. IT can give them greater Computer Security Access, so that they can use their growing experience to be people in the middle between the users who need help, and IT.
IT can show Power Users:
- How to adjust sequence in which stuff will print on printers, so that humongous reports do not delay delivery of smaller reports;
- How to arrange that all reports from one person are on hold, to be released at a particular time, so they are all together, not intermingled with everyone else's reports.
- How to identify individual tasks and what they are doing.
- How to rearange sequence of stuff in JOBQ without messing up inter-dependencies.
- Get in habit of using F4 key instead of ENTER key.
