XCF groups

An IBM Z Workload Scheduler XCF system consists of one Z controller and one or more trackers defined as members in the XCF group. You can include one or more standby Z 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 IBM Z Workload Scheduler group in a sysplex. For example, you might want to have a test and production IBM Z Workload Scheduler group in your sysplex.

IBM Z Workload Scheduler supports these sysplex configurations:

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

Note: Because IBM Z Workload Scheduler uses XCF signaling services, group services, and status monitoring services with permanent status recording, a couple data set is required. IBM Z Workload Scheduler does not support a local sysplex.

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 Z controller. IBM Z Workload Scheduler systems are either ACTIVE, FAILED, or NOT-DEFINED for the IBM Z Workload Scheduler XCF complex.

Each active member tracks the state of all other members in the group. If an IBM Z Workload Scheduler 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:

Z controller: When the Z 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 Z controller that is enabled for takeover detects that the Z controller has changed to failed state, it attempts to become the new Z controller. If there is more than one standby Z controller in the group, the first one to detect failure of the Z controller attempts to take over the Z controller functions.
tracker: When a tracker member detects that the Z controller or standby Z 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 Z controller or standby Z controller becomes active again it informs the tracker that it is ready to receive events.