  With the SPE of May Z Workload Scheduler (Zws) provides the possibility to automatically insert into the submitted JCL customized SYSAFF and CLASS JOB card keywords. All z/OS users know very well that SYSAFF card is used to force the execution of a job on the indicated systems and that CLASS assigns specific characteristics to the job, like holding, time and even return code handling logic (JOBRC). The point is: why this is important for Zws users?  In this blog we will concentrate on the SYSAFF replacement. So, the first answer is: To handle easily the LPAR planned shutdown We know that in a JES environment the submission of a job on a specific system does not guarantee the execution on the same system too. We also know that if we must shut down an LPAR for maintenance we do not want to interrupt the execution of jobs or delay too much the shutdown to wait jobs completion. Most of all we know that manual checks and actions are subject to human errors and automatic handling of the scenario is the best thing for reducing costs and needed resources. In Zws we already had the SHUTDOWNPOLICY parameter to handle this scenario: IF SHUTDOWNPOLICY is set the Engine before to submit the jobs will consider also their estimated duration and, whenever the estimated end is beyond the workstation availability, the job is not submitted. But what happens if the job is submitted on LPAR that will not be shut down so that the SHUTDOWNPOLICY checks are passed but … then JES decides to execute the job on a different LPAR (due to scheduling environment availability for example) and this LPAR will be shut down in a few times? We need that the SHUTDOWPOLICY checks guarantee also the JOB execution phase. SPE of May provides a very easy way to solve this scenario. Three Simple Steps  What makes this new feature easy and usable is:
JUST AN EXAMPLE: Let’s see how it works with an example. Suppose we have the following JES2 SYSPLEX with four LPAR:
 On every LPAR a tracker is running. For each Tracker we have a destination defined in the Controller initial parameter ROUTOPTS.  In this example we are using TCP/IP connection and TCZ1A, TCZ2A, TCZ3A and TCZ8A are the destination names to be used on the associated workstation definitions. We have a Virtual workstation, named VIRT, that includes all the four LPARs:   STEP 1 We have planned a shutdown of LPAR identified by TCZ2A the 10th and the 11th of December: the system will not be available from 15.00 to 23.59. We define appropriately the availability intervals of TCZ2A destination of Virtual workstation VIRT:  STEP 2 We define on initial parameter the SHUTDOWPOLICY parameter. The value 100 means that in the calculation of job estimated end within the SHUTDOWNPOLICY checks, we will consider the whole duration.  STEP 3 We define on JTOPTS initial parameter the new keyword WSSYSAFF as follows:  The format used is: WSSYSAFF(wsname:systemname.destination, … , systemname.destination) If you do not want to stop Controller, you can add the values dynamically with the following modify command addressed to the Controller subsystem (TWSZ):
Consider that with modify command you can add (AWSSYSAFF) or remove (RWSSYSAFF) new option values whenever you want. To maintain control of new options value you can use the modify command (DWSSYSAFF) to display current values: MODIFY COMMANDS TO CHANGE NEW OPTIONS INCREASE FEATURE USABILITY That’s all! Let us see now what happens if we submit the following JCL on VIRT workstation at 13.30. Job duration is 4 hours. This means that the job estimated end is at 17.30, within the unavailability range of TCZ2A destination. For SHUTDOWNPOLICY the job lasts too much to be completed in the open interval. What is new is that now the JCL is tailored to add the SYSAFF statement in the JOB card to exclude not only the submission but also the execution of the job on TCZ2A This is the job JCL saved in JS VSAM. No SYSAFF specified:  This is the JOBLOG of the submitted JCL showing the adding of SYSAFF statement:  What happened is that the SHUTDOWNPOLICY checks used the destinations specified in the WSSYSAFF statement for VIRT workstation to identify the availability intervals to be used. More in detail:
S012 is added to SYSAFF - For S013.TCZ2A the destination is not available from 15.00 to 23.59 (VIRT-TCZ2A) and the job estimated end is within this interval: S013 is NOT added to SYSAFF - For S014.TCZ3A there no unavailability interval (VIRT-TCZ3A) S014 is added to SYSAFF - For S088.TCZ8A there no unavailability interval (VIRT-TCZ8A) S088 is added to SYSAFF Note that the tailoring can be seen on job JOBLOG but it is not saved on Controller local repository (JS VSAM), because every tailoring is done ad hoc and related to the current situation at submission time: KEY POINTS OF JCL TAILORING  This scenario involved a Virtual workstation and make it more flexible and effective: with WSSYSAFF you can distributed the workload on different LPAR controlling also the execution when needed. Consider that WSSYSAFF can be used to force execution also for not Virtual workstations, having only one destination. The concept is the same. The planned shutdown is not the unique scenario that can be addressed by means of this new, feature. You could use it to group jobs per their characteristic and force execution on the most appropriate LPAR. For example you can use it: To execute more important jobs on LPAR more performant Suppose LPAR S088 is the most performant. The jobs that are most important should be defined on workstation HIGH including all four destinations The other jobs should be defined on Virtual workstation LOW including all four destinations We want to reserve LPAR S088 to the most important jobs. The WSSYSAFF statement should be: WSSYSAFF(HIGH:S088.TCZ8A, LOW:S012.TCZ1A,S013.TCZ2A,S014.TCZ3A)
In conclusion we can summarize the flow as follow:  Author' BIO
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
Archives
March 2023
Categories
All
|
RSS Feed