Controlling the system where a z/OS job is to be executed

As a normal behavior, HCL Workload Automation for Z submits the z/OS jobs on the tracker identified by the destination specified in the workstation definition. Before submitting the job, the controller checks the:
  • Workstation availability, such as workstation-open intervals, parallel servers, workstation resources R1 and R2.
  • The estimated duration of the job, if you set JTOPTS SHUTDOWNPOLICY.

However, the system where the job is submitted does not always coincide with the system where the job will be executed. JES could decide to execute the job to another system, where the required resources are available. As a consequence, the checks made by the controller on the system where the job is submitted do not guarantee that the same conditions are found in the system where the job will be executed.

You can prevent this situation by controlling the system where the job is to be executed. This is also useful when you want a job that is more critical to you to be run on systems with higher performance. Controlling the system where the job must be run is done on the controller by setting the following statement:
JTOPTS WSSYSAFF(wsname:system.destination)
Based on this setting, the following occurs:
  • A SYSAFF parameter is added to the job card at submission time. If a SYSAFF parameter was already set, it is overwritten with this value.
  • The SYSTEM parameter of the job card, if any, is deleted.

You can specify more than one couple system.destination for a single wsname, provided that those systems belong to the same SYSPLEX. The destination you specify is used to perform availability checks on the workstation.

For example, you have a SYSPLEX that comprises the following systems:
  • SYSA
  • SYSB
  • SYSC
  • SYSD
and on the controller you defined the destinations associated with the systems as follows:
  • Destination XCFA, associated with system SYSA
  • Destination XCFB, associated with system SYSB
  • Destination XCFC, associated with system SYSC
  • Destination XCFD, associated with system SYSD
To submit your jobs, you have defined the following virtual workstations:
  • VIRH, which is associated with destinations XCFA and XCFB (high performance)
  • VIRL, which is associated with destinations XCFC and XCFD (lower performance)
Because you want to run the most critical jobs on the systems with higher performance (in this example, SYSA and SYSB), and ordinary jobs on the systems with less resources (in this example, SYSC and SYSD), you submit the important jobs on workstation VIRH and the others on workstation VIRL. But you can also force the execution of those jobs on the systems that you prefer by setting JTOPTS as follows:
                (VIRL:SYSC.XCFC, SYSD.XCFD)
Note: The WSSYSAFF parameter is not applicable to Started task (STC) workstations.

You might also want to force the CLASS parameter of the job card, so that you can control the execution of that category of jobs. To do so, set JTOPTS WSCLASS(wsname) by specifying the workstation or workstations whose jobs you want to consider. The value that is applied to the CLASS parameter of the job card will be the CLASS value that is set for the job in the current plan. If no JOB CLASS or SYSOUT CLASS is specified in the CP, no CLASS forcing is performed.

For example, if you set:

the CLASS parameter of the job card is added or modified for all the jobs running on workstations CPU1 and VIRT, provided that those jobs are assigned a JOB CLASS or SYSOUT CLASS in the current plan.

For details about JTOPTS, see Customization and Tuning.