Cross-system multiregion operation (XCF/MRO)

The cross-system coupling facility (XCF) is part of the MVS™ base control program, providing high-performance communication links between MVS images that are linked in a sysplex (systems complex) by channel-to-channel links, channels, or coupling facility links.

IRC provides an XCF access method that makes it unnecessary to use z/OS® Communications Server to communicate between MVS images within the same MVS sysplex.

Each CICS® region is assigned to an XCF group when it logs on to IRC, even if it is not currently connected to any regions in other MVS images. You specify the name of the XCF group on the XCFGROUP system initialization parameter. If you do not specify XCFGROUP, the region becomes a member of the default CICS XCF group, DFHIR000.

When members of a CICS XCF group that are in different MVS images communicate, CICS selects the XCF access method dynamically, overriding the access method specified on the connection resource definition. By means of MVS cross-system coupling facility, MRO can function between MVS images in a sysplex environment, supporting all the usual MRO operations.

XCF/MRO does not support accessing shared data tables across MVS images. Shared access to a data table, across two or more CICS regions, requires the regions to be in the same MVS image. To access a data table in a different MVS image, you can use function shipping.

Each CICS region can be a member of only one XCF group, which it joins when it logs on to IRC. The maximum size of an XCF group is limited by the MVS MAXMEMBER parameter, with an absolute limit of 2047 members. If this limit is a problem because, for example, it limits the number of CICS regions you can have in your sysplex, you can create multiple XCF groups, each containing a different set of regions. You might, for example, have one XCF group for production regions and another for development and test regions. If you do need to have multiple XCF groups, follow these recommendations:
  • You put your production regions in a different XCF group from your development and test regions.
  • You do not create more XCF groups than you need; two, separated as described, may be sufficient.
  • You try not to move regions between XCF groups.
  • You try not to add or remove regions from existing XCF groups.

Note that CICS regions can use MRO or XCF/MRO to communicate only with regions in the same XCF group. Members of different XCF groups cannot communicate using MRO or XCF/MRO, even if they are in the same MVS image.

CICS regions linked by XCF/MRO can be at different release levels; see Multiregion operation. Depending on the versions of CICS installed in the MVS images participating in XCF/MRO, the versions of DFHIRP installed in the link pack areas of the MVS images can be different. If a single MVS image contains different releases of CICS, all using XCF/MRO to communicate with regions in other images in the sysplex, the DFHIRP module in the MVS LPA must be that from the most current CICS release in the image, or higher. However, note that the CICS TS for z/OS, Version 4.1 version of DFHIRP (required for multiple XCF group support) can be used only on z/OS Version 1.7 or later. For full details of software and hardware requirements for XCF/MRO, see Installation requirements for XCF/MRO.

Figure 1 is an example of the use of XCF/MRO in a sysplex environment. This example, has only one CICS XCF group, DFHIR000. The members of DFHIR000 can communicate using XCF/MRO links across the two MVS images.

The MRO links between CICS1 and CICS2 and between CICS3 and CICS4 use either the IRC or XM access methods, as defined for the link. The MRO links between CICS regions on MVS1 and the CICS regions on MVS2 use the XCF method, which is selected by CICS dynamically.

In each MVS, the DFHIRP module in the LPA must be at the level of the highest CICS TS for z/OS release in the image.

Figure 1. A sysplex (SYSPLEX1) containing a single CICS XCF group.
The picture shows a sysplex consisting of two MVS images, MVS1 and MVS2. It illustrates the configuration described in the text.

Figure 2 is a slightly more complex example. This example has two CICS XCF groups, DFHIR000 and DFHIR001. The members of each XCF group can communicate across the MVS images by means of XCF/MRO links.

To support multiple CICS XCF groups, both MVS images must be z/OS Version 1.7 or later and must use the CICS TS for z/OS, Version 3.2 or later version of DFHIRP. Although z/OS has supported multiple XCF groups since Version 1.6, CICS TS for z/OS, Version 3.2, which is required to join an XCF group other than DFHIR000 requires z/OS Version 1.7 or later.

Figure 2. A sysplex (SYSPLEX1) containing two CICS XCF groups
The picture shows a sysplex consisting of two MVS images, MVS1 and MVS2. It illustrates the configuration described in the text.
Note:
  • The members of the DFHIR000 XCF group in MVS1 (CICS 1, CICS 3, and CICS 4) use XCF/MRO, which is selected by CICS dynamically, to communicate with the member of the DFHIR000 XCF group in MVS2 (CICS 5). Similarly, CICS 2 in MVS1 uses XCF/MRO to communicate with CICS 6 in MVS 2; they are both members of the DFHIR001 group.
  • CICS 1, CICS 3, and CICS 4 cannot use XCF/MRO to communicate with CICS 6, because CICS 6 is in a different XCF group. Similarly, CICS 2 cannot use XCF/MRO to communicate with CICS 5.
  • Because they are in the same MVS image and the same XCF group, CICS 1, CICS 3, and CICS 4 can communicate with each other using either the MRO(IRC) or MRO(XM) access method, as defined for the links.
  • CICS 5 cannot use any form of MRO to communicate with CICS 6, even though they are in the same MVS image, because they are in different XCF groups. Similarly, CICS 2 cannot use any form of MRO to communicate with CICS 1, CICS 3, or CICS 4.