Coupling Facility
| Industry | Computer hardware, Computer software |
|---|---|
| Products | Coupling Facility Control Code (CFCC), Coupling Facility hardware and virtual machines |
In IBM System/390 and IBM Z mainframe computer environments, a Coupling Facility (CF) refers to either dedicated hardware or a virtual machine that manages coordination among multiple processors.
An Parallel Sysplex depends on one or more Coupling Facilities for operation. Typically, a CF is a mainframe processor configured within its own LPAR, equipped with dedicated physical CPs, and set up through the Hardware Management Console (HMC). It comprises memory and specialized communication channels known as CF Links, running the Coupling Facility Control Code (CFCC) operating system. The CF lacks conventional I/O devices apart from CF links, and all data is maintained in memory since CFCC does not utilize virtual memory. Generally, a CF contains tens of gigabytes of memory and does not execute application software.
Originally, CFCC operated on a separate 9674 mainframe unit with no I/O except for CF links. Subsequently, IBM introduced the Internal Coupling Facility on:
- IBM zSeries model 900 processors,
- IBM 9672 S/390 Parallel Enterprise Server G3 or later models,
- and all following z processors,
where CFCC runs inside an LPAR within the standard processor complex, communicating over internally simulated links. External CF links employ copper or optical fiber cabling. For enhanced availability, multiple CFs are typically deployed in a Sysplex cluster, with z/OS providing recovery capabilities to reconstruct structures on alternate CFs in case of failure.
Supported by CF technology, Sysplex clusters can scale efficiently to hundreds of CPUs across up to 32 members (each supporting as many as 190 CPUs), running transaction processing and database workloads. Data transfer between CF memory and connected systems uses direct memory access-like methods via CF links without interrupting active programs. Systems locally store CF data in bit vectors, enabling rapid access to key state information without querying the CF directly. The System z Architecture incorporates 18 specialized machine instructions plus other hardware enhancements to facilitate CF operations.
Coupling Facility structures
A Coupling Facility primarily supports three functions:
- Managing locking information shared among all connected systems
- Caching shared data (such as database contents) or maintaining consistency between local buffer pools
- Sharing data list information across systems
These functions are implemented through three categories of structures:
- Lock
- Cache
- List (which includes Serialised List)
Each structure corresponds to a designated portion of CF memory accessed by specific CF-aware applications running on coupled z/OS systems. A typical Parallel Sysplex includes multiple instances of each structure type. For example, each Db2 Data Sharing Group employs one Lock structure, one List structure, and several Cache structures—one per Group Buffer Pool.
Structure duplexing
Structures may be duplexed across two different CFs to maintain synchronized copies. This duplexing approach mitigates single points of failure by enabling one CF to continue servicing requests if the other becomes unavailable, thereby reducing application downtime.
Coupling Facility requests
Requests directed at CF structures fall into two categories:
- Synchronous (sync): the z/OS system waits until the request completes, actively spinning its processor during the wait. Sync requests provide fast responses but consume considerable CPU resources on the coupled system.
- Asynchronous (async): the system does not wait for completion before proceeding. Async requests have lower priority and slower response times but avoid processor spinning.
Applications running on z/OS explicitly select either synchronous or asynchronous modes when making CF requests.
Dynamic Request Conversion
First introduced with z/OS Release 2, Dynamic Request Conversion evaluates sampled response times to determine if Sync requests should be transformed into Async ones. This decision takes into account variables such as the speed of coupled processors and their proximity to the CF. It is important to note that Async requests are never reverted back to Sync. This approach serves as a complement to a prior method that converted requests based on factors like path congestion and data volume but did not incorporate dynamic sampling of response times.
Coupling Facilities (CFs) are unique to S/390, zSeries, and System z mainframes and play a pivotal role in the Parallel Sysplex architecture.
Coupling Facility Levels and Software Integration
CFCC code is distributed in distinct Levels, each identified by a CFLEVEL number (for example, CFLEVEL 15, released in April 2007). These levels introduce new capabilities and performance improvements, frequently necessitating simultaneous updates to z/OS and related subsystems such as Db2. For example, features like Coupling Facility Structure Duplexing rely on these synchronized software upgrades. In some cases, support may be delivered through PTFs rather than full version releases.