Multi-access spool systems connected through shared DASD

Figure 27 shows two z/OS JES2 multi-access spool (MAS) complexes that are connected through shared DASD.

Systems A and B form a MAS complex. System A is the Tivoli Workload Scheduler for z/OS controlling system. It shares spool with System B, which is a controlled Tivoli Workload Scheduler for z/OS system. Work is sent directly to this complex by the controller on System A. The work is processed on one of these two systems, depending on installation parameters. You represent this complex to Tivoli Workload Scheduler for z/OS by defining a computer workstation with a blank destination field. That is, all work for this workstation is submitted to the system that the controller is started on.

Figure 27. Two z/OS JES2 MAS complexes connected through shared DASD

Systems C and D, which are both Tivoli Workload Scheduler for z/OS controlled systems, form a second MAS complex. Work is sent to this complex via a submit/release data set. The destination field in the workstation description that represents this complex contains the DD name of the submit/release data set. The tracker on System C reads this data set and passes any new work to the complex for processing.

A tracker is installed on each system in the configuration. The event writer subtask of the tracker on each system writes events to an event data set on that system. Four event-reader subtasks, one for each of the event data sets, are started in the controller on System A. The controller reads the event data sets and updates the current plan.

When the controller is started on system A, it attempts to open the submit/release data set. If an I/O error occurs, the status of the workstation that represents the controlled MAS complex is set to offline. Tivoli Workload Scheduler for z/OS can then take automatic-workload-restart actions for operations at this workstation. These actions depend on the values that you specified on the WSOFFLINE keyword of the JTOPTS initialization statement.

Table 50 shows the initialization statements you can use to create the configuration in Figure 27. This example assumes that some of the planned Tivoli Workload Scheduler for z/OS work on System C is submitted by a non-Tivoli Workload Scheduler for z/OS process. To control this work, the hold/release function is used. HOLDJOB(USER) is specified on the EWTROPTS statement for the tracker on System C. The RELDDNAME keyword is specified on the ERDROPTS statement of the event reader that reads event data set C. This keyword identifies the DD name of the submit/release data set that the controller should write release commands to.

OPCOPTS    OPCHOST(YES)
           ERDRTASK4(4)
           ERDRPARM(ERDRA,ERDRB)
           ERDRC,ERDRD
ROUTOPTS   DASD(SUDSC)

OPCOPTS    OPCHOST(NO)
           ERDRTASK(0)
           EWTRTASK(YES)
           EWTRPARM(TRKAEW)
TRROPTS    HOSTCON(DASD)

ERDROPTS   ERSEQNO(1)

EWTROPTS

ERDROPTS   ERSEQNO(2)

ERDROPTS   ERSEQNO(3)
           RELDDNAME(SUDSC)

ERDROPTS   ERSEQNO(4)

OPCOPTS    OPCHOST(NO)
           ERDRTASK(0)
           EWTRTASK(YES)
           EWTRPARM(TRKBEW)
TRROPTS    HOSTCON(DASD)

EWTROPTS

OPCOPTS    OPCHOST(NO)
           ERDRTASK(0)
           EWTRTASK(YES)
           EWTRPARM(TRKCEW)
TRROPTS    HOSTCON(DASD)

EWTROPTS   SUREL(YES
           HOLDJOB(USER)

OPCOPTS    OPCHOST(NO)
           ERDRTASK(0)
           EWTRTASK(YES)
           EWTRPARM(TRKDEW)
TRROPTS    HOSTCON(DASD)

EWTROPTS