Dynamic cross-system coupling

XCF links can carry IP traffic. With DVIPA, XCF was used to communicate signalling information such as when a new instance of an IP address has been dynamically activated on a TCP/IP stack within the sysplex. The next step in the progression of utilizing a sysplex's capabilities is to use XCF to carry IP traffic.

VTAM and XCF

In order for TCP/IP to take advantage of inter-LPAR communication, VTAM must already have cross-system Coupling Facility (XCF) communications active. VTAM uses XCF to establish a common membership group, ISTXCF, that TCP/IP uses when communicating over dynamic XCF connections.

Establishing the links

When dynamic XCF is functional within a sysplex, a point-to-multipoint network is established among all participating LPARs. Each host in the sysplex has a direct connection to any other host in the same sysplex.

Within the TCP/IP profile data set, there is only one configuration option required, DYNAMICXCF. This option falls within the IPCONFIG statement group, as shown in Figure 1.

Figure 1. DYNAMICXCF option of IPCONFIG statement

 IPCONFG
        DYNAMICXCF 192.168.80.1 255.255.255.0 2

The definition in Figure 1 would cause the TCP/IP stack to create a link using the IP address of 192.168.80.1 within the sysplex subnetwork. This IP address would be directly reachable on the sysplex point-to-multipoint network by any other TCP/IP stack in the sysplex that also has DYNAMICXCF coded. Each TCP/IP stack would code a unique IP address within the same subnetwork.

When a TCP/IP stack becomes active in the sysplex and this stack has DYNAMICXCF coded, the following sequence of events occurs internally within the TCP/IP stack:

A DEVICE statement for this stack's XCF device is automatically generated.
A corresponding LINK statement is automatically generated.
A HOME statement entry using the DYNAMICXCF IP address is added to the active HOME list for the stack.
The device is started.

If a TCP/IP stack does not have DYNAMICXCF coded, it does not participate in the dynamic XCF communications. In other words, both end points must code DYNAMICXCF in order for a link to be established.

Note: All dynamic XCF statements must use a common network ID. This is because they form a point-to-multipoint network type.

More than just XCF

There are two special instances of dynamic XCF links that deserve further discussion.

If available, TCP/IP uses a HiperSockets link in preference to a Coupling Facility link. The reason is speed–HiperSockets is faster.

Dynamic XCF also functions within an LPAR when more than one TCP/IP stack is active in the same LPAR. The link generated is referred to as a samehost link, which corresponds to a device type of IUTSAMEH.

Consequently, the DEVICE and LINK statements generated by the TCP/IP stack vary depending upon whether a HiperSockets link is available and whether the link is within or between LPARs.

Figure 2 illustrates a simplified network layout showing the dynamic XCF definitions for a sysplex. Each TCP/IP stack has a unique IP address to represent itself in the dynamic XCF subnetwork. The dynamic XCF IP addresses of each participating TCP/IP stack are all in the same subnetwork.

When a new LPAR is added to the sysplex, assuming it is configured appropriately, it automatically joins the sysplex and activate its IP address within the dynamic XCF network.

Figure 2. Dynamic XCF network sample