Unicenter CA-Scheduler Job Management for VSE User Guide
Unicenter CA-Scheduler Job Management for VSE User Guide Unicenter CA-Scheduler Job Management for VSE User Guide
3.9 Defining Jobs 3.9.3.7 Once a Job Starts, How Can You Intervene? Unicenter CA-Scheduler offers several commands that allow users to control a job, but a job's definition also allows you to define control points during a job's processing. Ordinarily, you do not want to intervene in job processing. However, Unicenter CA-Scheduler gives you that ability should you need it. MEMO defines text to display at the system console when this job starts at the CPU. This happens every time that job runs. A MEMO of up to 60 characters forces the operator to reply OK or TERM. If the reply is OK, the job runs, but a reply of TERM causes Unicenter CA-Scheduler to cancel the job. Although manual intervention is what Unicenter CA-Scheduler tries to eliminate, there may be times when you need it. For example, Unicenter CA-Scheduler may control a job that needs to have an online database closed to users before it starts. Or another job may need onsite approval before it starts. These instances show how the MEMO option can be used. MEMO allows you to control a job when it starts, and INTERRUPT gives you control when a job ends. INTERRUPT = YES prevents a job from automatically being posted COMPLETED even though it ended successfully. Instead, it's given a status of INTRPTD which prevents the job's successors from being posted as satisfied. That gives you the chance to review the job's output. For example, you can check a trial balance to see if it is correct. If so, you can change the job's status to ENDED so its successors can be reevaluated to see if they can run, but if you are not satisfied with the output, you can rerun an interrupted job using the RERUN or SUBMIT command. 3.9.3.8 What Happens When Jobs Don't End Successfully? Several fields on the job base record determine what happens when something goes wrong or when unusual circumstances occur: ■ ■ ■ ■ ABEND BACKLOG FAIL CODE RECOVERABLE What if the system crashes while a job is running? Will Unicenter CA-Scheduler automatically restart the job? RECOVERABLE on the job record tells Unicenter CA-Scheduler if a job can be restarted after the system is re-IPLed. RECOVERABLE defaults to NO, which causes Unicenter CA-Scheduler to put the job on hold. The job waits to be canceled or released, but if RECOVERABLE = YES, Unicenter CA-Scheduler automatically releases the job after you restart the system. What if a job abends (cancels without going to normal completion)? A job's ABEND field allows a variety of things to happen: 3-68 Unicenter CA-Scheduler User Guide
3.9 Defining Jobs ■ ■ ■ ■ Ordinarily, Unicenter CA-Scheduler prevents successors to this job from being satisfied. That is what happens when ABEND = ABORT, which is the default. Alternatively, Unicenter CA-Scheduler can ignore that this job abended. If ABEND = CONT, successors continue to be satisfied as usual even if this job abends. If you specify ABEND=BACKOUT, Unicenter CA-Scheduler automatically submits a backout job when the job abends. A value must be specified for the BACKOUT installation option. Successors to the job will not be posted as satisfied. Unicenter CA-Scheduler adds a new job tracking record for the backout job. The backout job's name is constructed according to the BACKOUT installation option by altering one character position of the abended job's name. The backout job will be specified as ABEND=ABORT to prevent resubmission if the backout job itself abends. All other job attributes are copied from the abended job. Unicenter CA-Scheduler's fourth alternative prevents successors from being satisfied and begins processing another schedule instead. Specify that schedule's name (up to eight characters) as the value for ABEND. This alternative is a valuable rerun tool. Suppose that a job runs to normal completion but returns a completion code greater than zero. What happens then? It depends on the value you define for FAIL CODE on the job base record. FAIL CODE specifies the threshold for determining whether a job failed. If any job ends with a return code greater than or equal to the value defined for FAIL CODE, Unicenter CA-Scheduler gives that job a status of FAILED which means successors to this job will not be satisfied. Values for FAIL CODE can range from 1 to 4095. If FAIL CODE = 0 on the job base record, Unicenter CA-Scheduler does not check return codes. What will happen if a job never runs at all? If the production workload is too great, what happens to the selected jobs that do not run? The term backlog identifies jobs that do not run on the day they are scheduled and are carried over to the next day's workload. If BACKLOG=NO on a schedule base record, that schedule's jobs will never be backlogged unless you override this value on job records. Jobs will only be backlogged if: 1) BACKLOG = YES on their job base records, or 2) the job is submitted or started at the time of the next autoscan. Suppose a job is carried over into tomorrow's workload. What happens if that job is selected again tomorrow? Tomorrow's job is added to the workload after today's backlogged schedule has completed or been canceled. Chapter 3. Maintaining the Database 3-69
- Page 75 and 76: 3.1 Defining Schedules A Value Of U
- Page 77 and 78: 3.2 Defining Optional Schedule Reco
- Page 79 and 80: 3.2 Defining Optional Schedule Reco
- Page 81 and 82: 3.2 Defining Optional Schedule Reco
- Page 83 and 84: 3.2 Defining Optional Schedule Reco
- Page 85 and 86: 3.2 Defining Optional Schedule Reco
- Page 87 and 88: 3.3 Copying Schedules 3.3 Copying S
- Page 89 and 90: 3.3 Copying Schedules To Copy A Sch
- Page 91 and 92: 3.4 Displaying Schedules SCHD-SU S
- Page 93 and 94: 3.4 Displaying Schedules PRESS ENTE
- Page 95 and 96: 3.5 Deleting Schedules SCHD-SD SC
- Page 97 and 98: 3.5 Deleting Schedules If you are n
- Page 99 and 100: 3.6 Analyzing Schedules SCHD-UTIL
- Page 101 and 102: 3.6 Analyzing Schedules Unicenter C
- Page 103 and 104: 3.7 Automatic Console Replies for S
- Page 105 and 106: 3.7 Automatic Console Replies for S
- Page 107 and 108: 3.7 Automatic Console Replies for S
- Page 109 and 110: 3.8 Summary of Schedule Maintenance
- Page 111 and 112: 3.9 Defining Jobs 3.9 Defining Jobs
- Page 113 and 114: 3.9 Defining Jobs SCHD-JU JOB DEF
- Page 115 and 116: 3.9 Defining Jobs SCHD-JM JOB MAIN
- Page 117 and 118: 3.9 Defining Jobs 3.9.3.3 When Will
- Page 119 and 120: 3.9 Defining Jobs The chart precedi
- Page 121 and 122: 3.9 Defining Jobs those with earlie
- Page 123 and 124: 3.9 Defining Jobs 3.9.3.5 What JCL
- Page 125: 3.9 Defining Jobs If You Have multi
- Page 129 and 130: 3.9 Defining Jobs When you are read
- Page 131 and 132: 3.9 Defining Jobs If You Want Notif
- Page 133 and 134: 3.9 Defining Jobs If You Want To Se
- Page 135 and 136: 3.9 Defining Jobs The Job Criteria
- Page 137 and 138: 3.9 Defining Jobs The criteria stat
- Page 139 and 140: 3.9 Defining Jobs ■ MAXIMUM TIMEs
- Page 141 and 142: 3.9 Defining Jobs DESTINATIONS and
- Page 143 and 144: 3.9 Defining Jobs For These Message
- Page 145 and 146: 3.9 Defining Jobs To Separate All J
- Page 147 and 148: 3.9 Defining Jobs 3.9.4.6 Defining
- Page 149 and 150: 3.10 Displaying and Updating a Job
- Page 151 and 152: 3.10 Displaying and Updating a Job
- Page 153 and 154: 3.10 Displaying and Updating a Job
- Page 155 and 156: 3.11 Deleting Job Records 3.11 Dele
- Page 157 and 158: 3.11 Deleting Job Records SCHD-JM
- Page 159 and 160: 3.12 Analyzing Jobs 3.12 Analyzing
- Page 161 and 162: 3.12 Analyzing Jobs To display a fu
- Page 163 and 164: 3.13 Automatic Console Replies for
- Page 165 and 166: 3.13 Automatic Console Replies for
- Page 167 and 168: 3.13 Automatic Console Replies for
- Page 169 and 170: 3.14 Summary of Job Maintenance 3.1
- Page 171: 3.14 Summary of Job Maintenance To
- Page 174 and 175: 4.1 Online Monitoring Panel 4.1 Onl
3.9 Defining <strong>Job</strong>s<br />
3.9.3.7 Once a <strong>Job</strong> Starts, How Can You Intervene?<br />
<strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong> offers several commands that allow users to control a<br />
job, but a job's definition also allows you to define control points during a job's<br />
processing. Ordinarily, you do not want to intervene in job processing.<br />
However, <strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong> gives you that ability should you need it.<br />
MEMO defines text to display at the system console when this job starts at the<br />
CPU. This happens every time that job runs. A MEMO of up to 60 characters<br />
<strong>for</strong>ces the operator to reply OK or TERM. If the reply is OK, the job runs, but<br />
a reply of TERM causes <strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong> to cancel the job.<br />
Although manual intervention is what <strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong> tries to<br />
eliminate, there may be times when you need it. For example, <strong>Unicenter</strong><br />
<strong>CA</strong>-<strong>Scheduler</strong> may control a job that needs to have an online database closed<br />
to users be<strong>for</strong>e it starts. Or another job may need onsite approval be<strong>for</strong>e it<br />
starts. These instances show how the MEMO option can be used.<br />
MEMO allows you to control a job when it starts, and INTERRUPT gives you<br />
control when a job ends. INTERRUPT = YES prevents a job from automatically<br />
being posted COMPLETED even though it ended successfully. Instead, it's<br />
given a status of INTRPTD which prevents the job's successors from being<br />
posted as satisfied. That gives you the chance to review the job's output. For<br />
example, you can check a trial balance to see if it is correct. If so, you can<br />
change the job's status to ENDED so its successors can be reevaluated to see if<br />
they can run, but if you are not satisfied with the output, you can rerun an<br />
interrupted job using the RERUN or SUBMIT command.<br />
3.9.3.8 What Happens When <strong>Job</strong>s Don't End Successfully?<br />
Several fields on the job base record determine what happens when something<br />
goes wrong or when unusual circumstances occur:<br />
■<br />
■<br />
■<br />
■<br />
ABEND<br />
BACKLOG<br />
FAIL CODE<br />
RECOVERABLE<br />
What if the system crashes while a job is running? Will <strong>Unicenter</strong><br />
<strong>CA</strong>-<strong>Scheduler</strong> automatically restart the job? RECOVERABLE on the job record<br />
tells <strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong> if a job can be restarted after the system is<br />
re-IPLed. RECOVERABLE defaults to NO, which causes <strong>Unicenter</strong><br />
<strong>CA</strong>-<strong>Scheduler</strong> to put the job on hold. The job waits to be canceled or released,<br />
but if RECOVERABLE = YES, <strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong> automatically releases<br />
the job after you restart the system.<br />
What if a job abends (cancels without going to normal completion)? A job's<br />
ABEND field allows a variety of things to happen:<br />
3-68 <strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong> <strong>User</strong> <strong>Guide</strong>