XCF groups

An HCL Workload Automation for Z 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 HCL Workload Automation for Z group in a sysplex. For example, you might want to have a test and production HCL Workload Automation for Z group in your sysplex.

HCL Workload Automation for Z supports these sysplex configurations:
MULTISYSTEM
XCF services are available to HCL Workload Automation for Z started tasks residing on different z/OS systems.
MONOPLEX
XCF services are available only to HCL Workload Automation for Z started tasks residing on a single z/OS system.
Note: Because HCL Workload Automation for Z uses XCF signaling services, group services, and status monitoring services with permanent status recording, a couple data set is required. HCL Workload Automation for Z 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 controller. HCL Workload Automation for Z systems are either ACTIVE, FAILED, or NOT-DEFINED for the HCL Workload Automation for Z XCF complex.

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