A z/OS Sysplex

Figure 29 shows four systems, each connected by cross-system coupling facility (XCF) communication links.

System A is the controlling Tivoli Workload Scheduler for z/OS system and Systems B, C, and D are controlled systems. You represent each system in the systems complex (Sysplex) by a computer workstation. The destination field contains the XCF-group-member name of the Tivoli Workload Scheduler for z/OS started task. On the controlling system, you can leave the destination field of the workstation that represents System A blank, or you can specify the XCF-group-member name of the tracker on that system. If you leave the field blank, the controller passes work to the system for processing. If you specify the tracker XCF-group-member name, the controller transmits work to the tracker, which in turn passes the work to this system. The way that you define this workstation depends on the recovery strategy you want to use.

Figure 29. A z/OS Sysplex

A tracker is installed on each system in the sysplex. Each tracker event-writer subtask is started with a reader function, EWSEQNO is defined in the EWTROPTS statement. This means that the event writer passes the events to XCF for transfer to the controller at the same time as they are written to the event data set. This eliminates the need for separate event-reader subtasks.

XCF services let you define standby controllers, which act as a backup to the controller in case a failure occurs on the controlling system. This support is referred to as the hot standby function. In Figure 29, a Tivoli Workload Scheduler for z/OS address space is started on System B in standby mode. It is a copy of the controller but does not perform any functions unless the controller fails or System A fails. The standby controller must have access to all Tivoli Workload Scheduler for z/OS data, because it becomes the controller in the event of a failure.

The full functions of workload restart are available in this configuration. If a z/OS system failure occurs, the workstation that represents that destination is set to failed. Actions are taken according to the WSFAILURE keyword of the JTOPTS initialization statement. If a tracker fails or if the communication link between the controller and the tracker fails, the workstation is set to offline. Tivoli Workload Scheduler for z/OS takes actions according to the WSOFFLINE keyword of JTOPTS.

Table 52 shows the initialization statements you can use to create the configuration in Figure 29.

OPCOPTS  OPCHOST(YES)
         ERDRTASK(0)
ROUTOPTS XCF(SYSATRK,SYSBTRK,
             SYSCTRK,SYSDTRK)
XCFOPTS  GROUP(OPCGRP)
         MEMBER(CONTR)

OPCOPTS OPCHOST(NO)
        ERDRTASK(0)
        EWTRTASK(YES)
        EWTRPARM(TRKAEW)
XCFOPTS GROUP(OPCGRP)
        MEMBER(SYSATRK)
TRROPTS HOSTCON(XCF)

EWTROPTS EWSEQNO(1)

OPCOPTS OPCHOST(NO)
        ERDRTASK(0)
        EWTRTASK(YES)
        EWTRPARM(TRKBEW)
XCFOPTS GROUP(OPCGRP)
        MEMBER(SYSBTRK)
TRROPTS HOSTCON(XCF)

OPCOPTS  OPCHOST(STANDBY)
         ERDRTASK(0)
ROUTOPTS XCF(SYSATRK,SYSBTRK,
             SYSCTRK,SYSDTRK)
XCFOPTS  GROUP(OPCGRP)
         MEMBER(STBYCTRB)

EWTROPTS EWSEQNO(1)

OPCOPTS OPCHOST(NO)
        ERDRTASK(0)
        EWTRTASK(YES)
        EWTRPARM(TRKCEW)
XCFOPTS GROUP(OPCGRP)
        MEMBER(SYSCTRK)
TRROPTS HOSTCON(XCF)

EWTROPTS EWSEQNO(1)

OPCOPTS OPCHOST(NO)
        ERDRTASK(0)
        EWTRTASK(YES)
        EWTRPARM(TRKDEW)
XCFOPTS GROUP(OPCGRP)
        MEMBER(SYSDTRK)
TRROPTS HOSTCON(XCF)

EWTROPTS EWSEQNO(1)