Rui Miguel Feio

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

ICFs are PUs in a CPC configured to run only CFCC code. The PUs are not shipped with a fixed function assignment, but are assigned during power-on reset (POR) or later non-disruptively by on demand offerings such as: CBU, CUoD, CIU, ON/OFF CoD.

Those offerings allow the customer to convert, in seconds, a non-characterizable PU in any PU personality type such as: CPU, ICF, IFL, zAAP, zIIP and SAP.

An ICF can reduce the cost of exploiting coupling facility technology because:

• ICFs are less expensive than CPs.
• An ICF has a special software license charge. Special PR/SM microcode prevents the defined ICF PUs from executing non-CFCC code such as z/OS.

Notes:

CBU – Capacity BackUp

CFCC – Coupling Facility Control Code

CIU – Customer Initiated Upgrade

CoD – Capacity on Demand

CP – Central Processor

CPC – Central Processor Complex

CPU – Central Processor Unit

CUoD – Capacity Upgrade on Demand

ICF – Internal Coupling Facility

IFL – Integrated Facility for Linux

POR – Power-On Reset

PR/SM – Processor Resource/System Manager

PU – Processor Units

SAP – System Assistance Processor

zAAP – z Application Assist Processor

zIIP – z Integrated Information Processor

A coupling facility is a special logical partition that runs the coupling facility control code (CFCC) and provides high-speed caching, list processing, and locking functions in a sysplex.

HCD enables you to specify whether a logical partition can be a coupling facility, operating system, or either on certain processors. You connect the coupling facility logical partition to a processor through the coupling facility channels.

With z/OS services, a component called XES allows authorized applications, such as subsystems and z/OS components, to use the coupling facility to cache data, exchange status, and access sysplex lock structures in order to implement high performance data sharing and rapid recovery from failures.

The coupling facility is defined using HCD and PR/SM panels. Once you have defined an LP to be a coupling facility, only the coupling facility control code can run in that LP. When you activate the coupling facility LP, the system automatically loads the CFCC from the support element (an internal laptop) of the CPC.

Implementing a coupling facility in your sysplex requires both hardware and software:

• CPC that supports the CFCC.
• CPCs on which one or more z/OS images run and which are capable of connecting to the coupling facility with CF links.
• Appropriate level of z/OS that allows an exploiter to access a desired function when managing the coupling facility resources.
• CFCC must implement the functions the exploiter needs.

Notes:

CF – Coupling Facility

CFCC – Coupling Facility Control Code

CPC – Central Processor Complex

HCD – Hardware Configuration Definition

LP – Logical Partition

PR/SM – Processor Resource/System Manager

XES – Cross-system Extended Services