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

supportcontent.ca.com
from supportcontent.ca.com More from this publisher
03.03.2015 Views

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

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!