A group is the set of related members defined to XCF by a multisystem application in which members of the group can communicate with other members of the same group. A group can span one or more of the systems in a sysplex and represents a complete logical entity to XCF.

Notes:

XCF – Cross-system Coupling Facility

A member is a specific function (one or more routines) of a multisystem application that is joined to XCF and assigned to a group by the multisystem application. A member concept applies to all authorized routines running in the address space that issued the IXCJOIN macro service. Only for termination purposes (resource clean-up), the member can be associated with an address space, job step, or task.

XCF terminates the member when its association ends. The same address space can have more than one group.

Notes:

XCF – Cross-system Coupling Facility

An application in a XCF context is a program that has various functions distributed across z/OS systems in a multisystem environment. An application or subsystem might consist of multiple instances, each running on a different system in the same sysplex. Typically, each instance performs certain functions for the application as a whole. Alternatively, each instance could perform all the application’s functions on a given system.

XCF services are available to authorized applications, such as subsystems and z/OS components, to use sysplex services.

Notes:

XCF – Cross-system Coupling Facility

• XCF – a sysplex couple data set to store information about its systems, the XCF groups and members running in the sysplex, and general status information.

• CFRM – The Coupling Facility Resource Management (CFRM) couple data set holds the CFRM policy, which allows you to define how MVS is to manage your coupling facility resources.

• SFM – The Sysplex Failure Management (SFM) couple data set holds the SFM policy, which allows you to define how system failures, signalling connectivity failures, and PR/SM reconfiguration actions are to be managed.

• WLM – The Workload Management (WLM) couple data set holds the WLM policy, which allows you to define service goals for workloads.

• ARM – The Automatic Restart Management (ARM) couple data set holds the policy that defines how MVS is to manage restarts for specific batch jobs and started tasks that are registered as elements of automatic restart management.

• LOGR - The system logger (LOGR) couple data set holds the policy that allows you to define log stream or structure definitions.

XCF provides the services that allow multisystem application functions (programs) on one z/OS system to communicate with functions on the same or other z/OS systems. The communication services are provided through authorized assembler macros and are as follows:

• Group services
• Signalling services
• Status monitoring services

Group Services

XCF Group Services provide ways for defining members to XCF, establishing them as part of a group, and allowing them to find out about the other members in the group. A member introduces itself to XCF through the IXCJOIN macro. If a member identifies a group exit routine, XCF uses this routine to notify this member about status changes that occur to other members of the group, or systems in the sysplex; thus, members can have the most current information about the other members in their group without having to query each other.

Signalling services

The Signalling Services control the exchange of messages between members of an XCF group. The sender of a message requests services from XCF signalling services. XCF uses buffer pools to communicate between members in the same system, and it uses buffer pools plus signalling paths (CTCs or a CF list structure) to send messages between systems in the sysplex.

Status monitoring services

Status monitoring services provide a way for members to determine their own operational status and to notify the other members of the group when that operational status changes. An installation-written status exit routine identified to XCF determines whether a member is operating normally. An installation-written group exit routine identified to XCF allows a member to maintain current information about other members in the group, and systems in the sysplex.

Server Time Protocol (STP) is a server-wide facility that provides capability for multiple z/OS systems to maintain TOD synchronization with each other and form a Coordinated Timing Network (CTN), that is, a collection of z/OS systems that are time synchronized to a time value.

The External Time Reference (ETR) connections will be replaced over time by the implementation of Server Time Protocol (STP), which makes use of coupling links to pass timing messages to the servers. Transition to STP makes it possible to have a Mixed Coordinated Network configuration. The Sysplex Timer provides the timekeeping information in a Mixed CTN. Once an STP-only configuration is established, the ETR connections are no longer needed. STP allows coexistence with Sysplex Timer in mixed configurations. The Sysplex Timer console is replaced by an HMC screen for each possible time zone.

A Base Sysplex configuration is a sysplex with no Coupling Facilities. The Base Sysplex can be composed of one or more z/OS systems that have an XCF sysplex name and in which the authorized programs (members) use XCF services. XCF services are available in both single and multisystem environments. A multisystem environment is defined as two or more z/OS systems residing on one or more CPCs’ logical partitions connected through CTCs.

A Base Sysplex is the first step to implementing a Parallel Sysplex. A Parallel Sysplex is a Base Sysplex plus the use of the Coupling Facility. So, when you introduce the coupling facility, XCF exploits the coupling facility, using it as a link between z/OS systems.

The communication link between XCFs could be through channel-to-channel adapters (CTCs) that allow data movement between XCF buffers in the systems through an I/O operation. Another option for linking is a CF list structure.

Notes:

CF – Coupling Facility

CPC – Central Processor Complex

CTC – Channel-To-Channel

XCF – Cross-system Coupling Facility

To enable the communication between a Coupling Facility (CF) Logical Partition and the z/OS LPARs, special types of high-speed CF links are required. These links are important because of the impact of link performance on CF request response times. For configurations covering large distances, time spent on the link can be the largest part of CF response time.

A CF link adapter can be shared between LPs, meaning the same adapter can transfer data from/to different z/OS systems to one CF, thus reducing the number of links needed. This is called Multiple Image Facility (MIF), the same name used for FICON and ESON channels.

CF links in the System z servers work in a mode called peer mode. In this mode we have even more flexibility with connections. For example, a single link adapter can be connected (multiple image facility) to both z/OS and a CF.

Notes:

CF – Coupling Facility

ESCON – Enterprise Systems Connection

FICON – Fibre Connection

LP – Logical Partition

LPAR – Logical Partition

MIF – Multiple Image Facility

The Coupling Facility LP is defined through HCD and Processor Resource/Systems Manager (PR/SM) panels on the Hardware Management Console (HMC). Once you have defined an LP to be a coupling facility LP, only the CFCC can run in that LP. When you activate the Coupling Facility LP, the system automatically loads the CFCC from the laptop Support Element (SE) hard disk of the CPC.

Its major functions are:

• Storage management
• Support for CF links
• Console services (HMC)
• Trace, logout, and recovery functions
• Provide support for the list, cache, and lock structures

Notes:

CF – Coupling Facility

CFCC – Coupling Facility Control Code

CPC – Central Processor Complex

HCD – Hardware Configuration Definition

HMC – Hardware Management Console

LP – Logical Partition

PR/SM – Processor Resource/System Manager

Coupling Facility Control Code is an IBM licensed Internal Code that always runs under an LPAR, regardless of whether the CF is in a standalone CPC or in a general purpose CPC (where CFCC LPs are together with z/OS LPs). A standalone CPC is a CPC only allowing LPs running CFCCs.

CFCC is a simple but efficient operating system where, for example, no virtual storage support is implemented. It has multiprocessing capabilities running multiple processors and when there is no work to do, it loops in the CF link waiting for work requests (the interrupt mechanism is not implemented).

Notes:

CF – Coupling Facility

CPC – Central Processor Complex

ICF – Internal Coupling Facility

LIC – Licensed Internal Code

LP – Logical Partition

LPAR – Logical Partition