Method of use

A sample for controlling VM workload from IBM Z Workload Scheduler is delivered on the sample file under member name EQQCVM. The sample member includes these parts:

Batch loader control statements for defining an application description to run a VM job.
An example of JCL to signal VM that a job is to be started.
A CMS EXEC called OPCWATCH, which is run in the AUTOLOG VM user. OPCWATCH receives the start signal from z/OS and drives the requested EXEC on VM.
A CMS EXEC called OPCSTAT, which can be used by OPCWATCH to signal the status change of the VM job to IBM Z Workload Scheduler.

To use IBM Z Workload Scheduler to drive VM operations, follow these steps:

Define a new IBM Z Workload Scheduler workstation, for instance VM, as a general workstation with the automatic reporting attribute. The advantage of having a separate workstation is that separate ready lists and reports can be produced for VM operations based on the workstation name.

Define an application VMJJJJ with these operations:

   CPU1 010  JOBNAME RJJJJ      'SEND START ORDER TO VM'
   VM   020  JOBNAME JJJJ       'TRACKS REAL EXECUTION OF EXEC'

The run cycle and other characteristics should be the same as for normal z/OS applications.

The figure below shows the member RJJJJ in the IBM Z Workload Scheduler JCL library. This JCL will be executed by the CPU1 operation.

Figure 1. Member RJJJJ in the IBM Z Workload Scheduler JCL library

  
     //RJJJJ    JOB  Job statement parameters according to
     //              your installation standards
     /*JOBPARM CARDS=100
     /*ROUTE PUNCH VMNODE.VMUSER
     //******************************************************************
     //*
     //*       A z/OS job to signal VM when the controlled job
     //*       is ready to be started on the VM system.
     //*
     //******************************************************************
     //B        EXEC PGM=IEBGENER
     //SYSPRINT DD SYSOUT=Q
     //SYSUT1   DD *
     JJJJ
     /*
     //SYSUT2   DD SYSOUT=B
     //SYSIN    DD DUMMY

The first record in the //SYSUT1 data stream contains the name of the EXEC to be executed, followed by any parameters that should be passed to the EXEC.

Set up a VM AUTOLOG user to await the arrival of any reader files. You can use a wait EXEC to drive the VM AUTOLOG user (such as the OPCWATCH EXEC supplied in member EQQCVM in the IBM Z Workload Scheduler sample library). When reader files are sent to this user, it processes the EXEC named in the //SYSUT1 data. The EXECs that are processed are logged in the file OPCA LOG A.
Note:
- Each VM EXEC that is processed should set a return code to indicate whether it has run successfully.
- The wait EXEC depends on the module WAKEUP to invoke its execution. The WAKEUP module is available in the VM/IPF distribution.

Figure 2 shows an example of controlling VM operations from IBM Z Workload Scheduler. In this example:

IBM Z Workload Scheduler running under z/OS sends EXEC name JJJJ to a VM user, which is running the OPCWATCH EXEC.
OPCWATCH invokes two other VM EXECs, JJJJ and OPCSTAT.
Before and after JJJJ is being processed, OPCSTAT reports the status to an IBM Z Workload Scheduler general automatic-reporting workstation VM.
In z/OS, the jobs from VM execute a program to perform automatic-event reporting for the particular combination of application ID VMJJJJ, job name JJJJ, and status.

eqqc20f1 Figure showing an example of how to control VM operations from IBM Z Workload Scheduler. — Figure 2. Using automatic-event reporting to control VM operations

If IBM Z Workload Scheduler running under z/OS fails or if the communication link fails, a printed workstation plan and an IBM Z Workload Scheduler ready list from daily planning will still exist. This information tells which jobs must be run and the order in which they must be run. An IBM Z Workload Scheduler VM-user log lists the EXECs that have been started and those that have been completed. With this information, processing can continue either automatically when the link is reestablished or manually.

The jobs transmitted to and from VM add little additional load to z/OS. To avoid delays, a dedicated job class and initiator should be reserved for VM communication.

Because IBM Z Workload Scheduler does not require shared DASD for the preceding method, this method can be used to drive multiple VM users in different locations. You can also use this method to drive other z/OS systems. This method is particularly useful when a remote z/OS system runs a small number of backups and cleanups that are initiated and controlled from a central site.