XCF groups

A Tivoli Workload Scheduler for z/OS XCF system consists of one controller and one or more trackers defined as members in the XCF group. You can include one or more standby controllers in the group. If you want to connect the Data Store to the controller via XCF, you need to define a specific XCF group for them, different to the one defined to connect the controller to the z/OS® tracker.You can also specify more than one Tivoli Workload Scheduler for z/OS group in a sysplex. For example, you might want to have a test and production Tivoli Workload Scheduler for z/OS group in your sysplex.

Tivoli Workload Scheduler for z/OS supports these sysplex configurations:

MULTISYSTEM: XCF services are available to Tivoli Workload Scheduler for z/OS started tasks residing on different z/OS systems.
MONOPLEX: XCF services are available only to Tivoli Workload Scheduler for z/OS started tasks residing on a single z/OS system.

Note:

Because Tivoli Workload Scheduler for z/OS uses XCF signaling services, group services, and status monitoring services with permanent status recording, a couple data set is required. Tivoli Workload Scheduler for z/OS does not support a local sysplex.

For more information about setting up and running a sysplex, see Sysplex Management

With XCF communication links, the controller can submit workload and control information to trackers that use XCF signaling services. The trackers use XCF services to transmit events to the controller. Tivoli Workload Scheduler for z/OS systems are either ACTIVE, FAILED, or NOT-DEFINED for the Tivoli Workload Scheduler for z/OS XCF complex.

Each active member tracks the state of all other members in the group. If a Tivoli Workload Scheduler for z/OS group member becomes active, stops, or terminates abnormally, the other active members are notified. This list describes the actions taken by each started task in the group:

controller: When the controller detects that a tracker member changes to failed state, it stops sending work to the tracker. When it detects that a tracker has become active, it sends work to the tracker system and instructs the tracker to start transmitting event information.
Standby: When a standby controller that is enabled for takeover detects that the controller has changed to failed state, it attempts to become the new controller. If there is more than one standby controller in the group, the first one to detect failure of the controller attempts to take over the controller functions.
Tracker: When a tracker member detects that the controller or standby controller has failed, it stops sending event information. The tracker member continues to collect events and writes them to the event data set. When the controller or standby controller becomes active again it informs the tracker that it is ready to receive events.