Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
164 <strong>File</strong> <strong>Management</strong> V4R5<br />
If a job becomes active, it is possible to place it back on a job queue. See the Work<br />
<strong>Management</strong> book for a discussion of the Transfer Job (TFRJOB) and Transfer Batch<br />
Job (TFRBCHJOB) commands.<br />
Job queue security<br />
You can maintain a level of security with your job queue by authorizing only<br />
certain persons (user profiles) to that job queue. In general, there are three ways<br />
that a user can become authorized to control a job queue (for example, hold or<br />
release the job queue):<br />
v User is assigned spool control authority (SPCAUT(*SPLCTL)) in the user’s user<br />
profile.<br />
v User is assigned job control authority (SPCAUT(*JOBCTL)) in the user’s user<br />
profile and the job queue can be controlled by the operator (OPRCTL(*YES)).<br />
v User has the required object authority to the job queue. The required object<br />
authority is specified by the AUTCHK parameter on the CRTJOBQ command. A<br />
value of *OWNER indicates that only the owner of the job queue is authorized<br />
via the object authority for the job queue. A value of *DTAAUT indicates that<br />
users with *CHANGE authority for the job queue are authorized to control the<br />
job queue.<br />
Note: The specific authority required for *DTAAUT are *READ, *ADD, and<br />
*DLT data authority.<br />
See the CL Reference for more information about authority requirements for<br />
individual commands.<br />
These three methods of authorization apply only to the job queue, not to the jobs<br />
on the job queue. The normal authority rules for controlling jobs apply whether the<br />
job is on a job queue or whether it is currently running. See the Work <strong>Management</strong><br />
book for details on the authority rules for jobs.<br />
Job queue recovery<br />
If a command fails or the system stops abnormally while a reader or a submit jobs<br />
command is running and a partial job (not all the input stream has been read) is<br />
placed on the queue, the entire job must be resubmitted to the job queue.<br />
If a job is on a job queue when the system stops abnormally without damaging<br />
that job queue, the job remains intact on the job queue and is ready to run when<br />
the system becomes active again.<br />
If the system stops abnormally while a job is running, the job is lost and must be<br />
resubmitted to the job queue.<br />
If a job queue becomes damaged such that it cannot be used, you will be notified<br />
by a message sent to the system operator message queue. The message will come<br />
from a system function when a reader, Submit Jobs command, or a job tries to put<br />
or take jobs from the damaged queue.<br />
A damaged job queue can be deleted using the Delete Job Queue (DLTJOBQ)<br />
command, or it will be deleted by the system during the next IPL. After a<br />
damaged job queue is deleted, all job files on the damaged job queue will be<br />
moved to output queue QSPRCLJOBQ in library QRCL. This is done by the
Change language