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
7.4 Restart/Recovery of Scheduled Jobs 7.4.3 Unicenter CA-Driver Considerations Implementing a job step restart process is inherently complex due to all of the variations of abend conditions. As with the implementation of any automated system, the 'cure' should not cause more disruption than the problem. For example, in a multi-step job, Step 5 abends. The determination is made through the automated process that exists today, that Step 5 relies on the temporary data set that was created in Step 2. Therefore, the data sets that were created in Steps 2, 3 and 4 must be removed from the VSAM USERCAT. What cannot be determined through any automated process is that the data set created by Step 1 and used for input by Step 2 was created using incorrect input. Herein lies the problem of automating the restart/recovery process. There are many options available to a data center to effect proper restart/recovery. A more automated method can be achieved by using Unicenter CA-Driver, an optional component of Unicenter CA-Scheduler/VSE. Unicenter CA-Driver is a powerful JCL and runtime management facility that can work hand-in-hand with Unicenter CA-Scheduler. You can define jobs to Unicenter CA-Scheduler that store their JCL with Unicenter CA-Driver-managed procedures. Unicenter CA-Driver controls the expansion of these 'procs' based upon values that you supply. When defining jobs to Unicenter CA-Scheduler that find their JCL in Driver procs, Unicenter CA-Scheduler will also ask you to define normal runtime parameters and rerun runtime parameters. The normal runtime parameters will be passed from Unicenter CA-Scheduler to Unicenter CA-Driver when it is time to submit the job. The panel (Unicenter CA-Driver restart parms) parameters will be passed from Unicenter CA-Scheduler to Unicenter CA-Driver whenever the job is being rerun using the Unicenter CA-Scheduler RERUN command. Thus, this facility gives you the flexibility to have your Unicenter CA-Driver procs expanded differently depending on the circumstances at the time. Unicenter CA-Driver also provides you with the ability to test VSE completion codes and return codes between steps of a job. The results of these tests can be used to execute steps of a job conditionally. Unicenter CA-Driver is a very useful tool. To really get to know all of the facilities of Unicenter CA-Driver and how they can be used, refer to your Unicenter CA-Driver Reference Guide. 7-18 Unicenter CA-Scheduler User Guide
7.5 Multiple CPU Considerations 7.5 Multiple CPU Considerations Unicenter CA-Scheduler, as you have seen throughout this manual, has a great deal of flexibility. When it comes to scheduling and controlling production on more than one CPU, this flexibility continues to exist. In this topic, however, we are going to discuss the manner in which most shops use Unicenter CA-Scheduler in a multi-CPU environment. First, you must get some basic IBM terminology out of the way. The term SYSID will be used throughout this chapter. SYSID is the system identifier that uniquely identifies each of the VSE operating systems that execute in your environment. This is established by the systems programmer when generating each of the VSE operating systems. At times, the SYSID is referred to as the POWER SYSID. You can allow POWER with shared spool to determine which CPU jobs run on. You do this through control of the CLASS designations. That is, if a job is to run in CLASS T, and there is a CLASS T on each CPU, then POWER will determine which CPU on which to run the job. There will be times, however, where you want a job to execute on a specific CPU (maybe it is the only place where a program can get to a specific database). In this case, you can direct POWER to execute the job on a specific CPU by specifying a RUN ON SYSID value in the job base record. If Unicenter CA-Scheduler is submitting your JCL from LIBTYPE=CMS, it may not be necessary to generate POWER with shared spool. In this case, the Unicenter CA-Scheduler CMS service machine will do what non-shared power spool cannot—route the JCL to the correct POWER SYSID. This can be accomplished by creating a file that contains the POWER SYSID and the VSE guest machine name. The file has a filename of SCDSYSID and a filetype of USERID and must reside on a CMS disk that is accessible to the Unicenter CA-Scheduler CMS service machine. The Unicenter CA-Scheduler CMS service machine will match the SYSID in this file with the RUN ON SYSID value (SYSID=) in the job base record and submit the job to the corresponding VSE guest machine. There must be at least one blank between the POWER SYSID and the VSE guest machine name as follows: 1 VSEPROD1 2 VSEPROD2 3 VSEPROD3 Unicenter CA-Scheduler will generate the appropriate POWER JECL JOB statement with the SYSID= parameter whenever a RUN ON SYSID is specified on the job base record. Chapter 7. Techniques 7-19
- Page 234 and 235: 5.3 Some Examples 5.3 Some Examples
- Page 236 and 237: 5.3 Some Examples Example 7 A payro
- Page 238 and 239: 5.3 Some Examples ■ ■ If the la
- Page 240 and 241: 5.4 What Is Wrong with These Exampl
- Page 242 and 243: 5.4 What Is Wrong with These Exampl
- Page 245 and 246: Chapter 6. Tips This topic of the m
- Page 247 and 248: 6.1 Commonly Asked Questions 6.1.1.
- Page 249 and 250: 6.1 Commonly Asked Questions Keep i
- Page 251 and 252: 6.1 Commonly Asked Questions 6.1.2.
- Page 253 and 254: 6.1 Commonly Asked Questions To all
- Page 255 and 256: 6.1 Commonly Asked Questions For de
- Page 257 and 258: 6.1 Commonly Asked Questions use of
- Page 259 and 260: 6.1 Commonly Asked Questions 6.1.4
- Page 261 and 262: 6.1 Commonly Asked Questions If the
- Page 263 and 264: 6.1 Commonly Asked Questions Status
- Page 265 and 266: 6.2 Pitfalls predecessor criteria o
- Page 267 and 268: Chapter 7. Techniques This chapter
- Page 269 and 270: 7.1 On-Request Schedules and Jobs 7
- Page 271 and 272: 7.1 On-Request Schedules and Jobs 7
- Page 273 and 274: 7.1 On-Request Schedules and Jobs W
- Page 275 and 276: 7.2 Backlogged Work completes on We
- Page 277 and 278: 7.3 Issuing Online Commands in Batc
- Page 279 and 280: 7.3 Issuing Online Commands in Batc
- Page 281 and 282: 7.3 Issuing Online Commands in Batc
- Page 283: 7.4 Restart/Recovery of Scheduled J
- Page 287 and 288: 7.5 Multiple CPU Considerations Nor
- Page 289 and 290: 7.5 Multiple CPU Considerations exe
- Page 291 and 292: 7.5 Multiple CPU Considerations CAJ
- Page 293 and 294: 7.6 NJE Processing In the preceding
- Page 295 and 296: 7.6 NJE Processing 7.6.2.1 NJE Job
- Page 297 and 298: 7.6 NJE Processing 7.6.4 Installati
- Page 299 and 300: 7.6 NJE Processing Status BUSY Mean
- Page 301 and 302: 7.7 Summing Up Prefix PW DM Transac
- Page 303 and 304: Glossary This glossary defines term
- Page 305 and 306: documentation batch command. A comm
- Page 307 and 308: Unicenter CA-Scheduler uses when or
- Page 309 and 310: The payroll department's month-end
- Page 311 and 312: Index Special Characters "Who is lo
- Page 313 and 314: Commands (continued) operator (cont
- Page 315 and 316: F FAIL CODE field 7-16 FAILED queue
- Page 317 and 318: MBR SUBID field 3-65 MCPU installat
- Page 319 and 320: Predecessors (continued) types (con
- Page 321 and 322: Scheduling (continued) jobs 1-5, 5-
- Page 323: User (continued) authority levels 2
7.5 Multiple CPU Considerations<br />
7.5 Multiple CPU Considerations<br />
<strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong>, as you have seen throughout this manual, has a great<br />
deal of flexibility. When it comes to scheduling and controlling production on<br />
more than one CPU, this flexibility continues to exist. In this topic, however,<br />
we are going to discuss the manner in which most shops use <strong>Unicenter</strong><br />
<strong>CA</strong>-<strong>Scheduler</strong> in a multi-CPU environment.<br />
First, you must get some basic IBM terminology out of the way. The term<br />
SYSID will be used throughout this chapter.<br />
SYSID is the system identifier that uniquely identifies each of the <strong>VSE</strong><br />
operating systems that execute in your environment. This is established by the<br />
systems programmer when generating each of the <strong>VSE</strong> operating systems. At<br />
times, the SYSID is referred to as the POWER SYSID.<br />
You can allow POWER with shared spool to determine which CPU jobs run<br />
on. You do this through control of the CLASS designations. That is, if a job is<br />
to run in CLASS T, and there is a CLASS T on each CPU, then POWER will<br />
determine which CPU on which to run the job. There will be times, however,<br />
where you want a job to execute on a specific CPU (maybe it is the only place<br />
where a program can get to a specific database). In this case, you can direct<br />
POWER to execute the job on a specific CPU by specifying a RUN ON SYSID<br />
value in the job base record.<br />
If <strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong> is submitting your JCL from LIBTYPE=CMS, it may<br />
not be necessary to generate POWER with shared spool. In this case, the<br />
<strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong> CMS service machine will do what non-shared power<br />
spool cannot—route the JCL to the correct POWER SYSID. This can be<br />
accomplished by creating a file that contains the POWER SYSID and the <strong>VSE</strong><br />
guest machine name. The file has a filename of SCDSYSID and a filetype of<br />
USERID and must reside on a CMS disk that is accessible to the <strong>Unicenter</strong><br />
<strong>CA</strong>-<strong>Scheduler</strong> CMS service machine. The <strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong> CMS<br />
service machine will match the SYSID in this file with the RUN ON SYSID<br />
value (SYSID=) in the job base record and submit the job to the corresponding<br />
<strong>VSE</strong> guest machine. There must be at least one blank between the POWER<br />
SYSID and the <strong>VSE</strong> guest machine name as follows:<br />
1 <strong>VSE</strong>PROD1 2 <strong>VSE</strong>PROD2 3 <strong>VSE</strong>PROD3<br />
<strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong> will generate the appropriate POWER JECL JOB<br />
statement with the SYSID= parameter whenever a RUN ON SYSID is specified<br />
on the job base record.<br />
Chapter 7. Techniques 7-19