To enable partitioning of the TCP/IP stacks and VTAM® nodes in a sysplex into subplexes, the values specified by the following VTAM start option and TCP/IP profile GLOBALCONFIG parameter are used as suffixes for XCF group names and coupling facility structure names.
- VTAM
Use the XCFGRPID start option. For a description of sysplex subplexing and how the XCFGRPID start option modifies VTAM group names and VTAM structure names, see z/OS Communications Server: SNA Network Implementation Guide.
- TCP/IP
Use the XCFGRPID parameter on the GLOBALCONFIG statement in the TCP/IP profile.
For TCP/IP, both the VTAM group ID suffix and the TCP group ID suffix can be used to modify the group name that a TCP/IP stack uses when it joins the sysplex. The group name used is in the form EZBTvvtt, where vv is the 2-digit VTAM group ID suffix specified on the XCFGRPID start option, and tt is the TCP group ID suffix specified on the GLOBALCONFIG statement in the TCP/IP profile. By using these suffixes to modify the XCF group name, the sysplex is effectively partitioned into subsets referred to as subplexes.
Only those TCP/IP stacks joining the unique group name generated using the specified suffixes are aware of each other in the sysplex; they communicate with each other through dynamic XCF. If the VTAM node is stopped and restarted with a new value for its XCFGRPID start option, the TCP/IP stacks using that VTAM node must be stopped and restarted to access the new VTAM suffix.
Figure 1 shows an example of TCP/IP and VTAM subplexes.
In Figure 1, the following subplexes are defined:
- Two VTAM subplexes (11 and 12) have been defined by starting VTAM1 and VTAM2 with a start option of XCFGRPID 11, and starting VTAM3 and VTAM4 with a start option of XCFGRPID 12.
- Three TCP/IP subplexes have been defined by starting TCP1A and TCP2A with the statement GLOBALCONFIG XCFGRPID 21, TCP1B and TCP2B with the statement GLOBALCONFIG XCFGRPID 22, and TCP3A and TCP4A with the statement GLOBALCONFIG XCFGRPID 12.
The following conditions exist in the sysplex shown in Figure 1:
- TCP/IP stacks TCP1A and TCP2A join XCF group EZBT1121. TCP1A is aware of only TCP2A in the sysplex, and TCP2A is aware of only TCP1A in the sysplex.
- TCP/IP stacks TCP1B and TCP2B join XCF group EZBT1122. TCP1B is aware of only TCP2B in the sysplex, and TCP2B is aware of only TCP1B in the sysplex.
- TCP/IP stacks TCP3A and TCP4A join XCF group EZBT1212. TCP3A is aware of only TCP4A in the sysplex, and TCP4A is aware of only TCP3A in the sysplex.
To preserve separation between the subplexes, the TCP and VTAM coupling facility structures accessed must also be unique for each subplex. For the TCP structures EZBDVIPA, used for SWSA support, and EZBEPORT, used for SYSPLEXPORTS support, this is accomplished by appending the VTAM and TCP XCF group ID suffixes to the end of the structure names, or EZBDVIPAvvtt and EZBEPORTvvtt respectively. Thus, in the example, TCP1A and TCP2A access EZBDVIPA1121 and EZBEPORT1121, while TCP1B and TCP2B access EZBDVIPA1122 and EZBEPORT1122.
To access the TCP structures, the structure names, including the suffixes, must be defined in the sysplex CFRM policy. In Figure 1, the CFRM policy for the sysplex must have structure definitions for EZBDVIPA1121, EZBDVIPA1122, EZBDVIPA1212, EZBEPORT1121, EZBEPORT1122, and EZBEPORT1212, if all of the stacks expect to access these structures.
- If no VTAM suffix is specified, a value of CP is used for vv when creating the TCP sysplex group name, and a value of 01 is used for vv when creating the structure names.
- If a VTAM suffix is specified, but no TCP suffix is specified, a value of CS is used for tt when creating the TCP sysplex group name, and a null value is used for tt when creating the structure names. Thus, in Figure 1, if TCP1B and TCP2B are started without an XCFGRPID parameter on their GLOBALCONFIG statements, the sysplex group they join is EZBT11CS, and the structures they can access are EZBDVIPA11 and EZBEPORT11.
To estimate the coupling facility size requirements for each of these structures, use the CFSizer website at http://www.ibm.com/systems/support/z/cfsizer/.
To isolate communication between different subplexes within a sysplex, dynamic XCF connectivity between TCP/IP stacks in different subplexes on separate MVS™ images is blocked. In addition, IUTSAMEH connectivity for dynamic XCF between stacks in different subplexes on the same MVS image is also blocked.
When using HiperSockets™ to establish dynamic XCF connectivity between TCP/IP stacks in the same CPC using the same HiperSockets CHPID, to preserve subplex isolation, specify the IQDVLANID parameter on the GLOBALCONFIG statement as follows:
- TCP/IP stacks in the same subplex that share the same CPC and specify the same HiperSockets CHPID must specify the same VLAN ID value on the IQDVLANID parameter.
- TCP/IP stacks in different subplexes that share the same CPC and specify the same HiperSockets CHPID must specify different VLAN ID values on the IQDVLANID parameter.
- If subplexing is not being used within the sysplex, do not specify the IQDVLANID parameter on the GLOBALCONFIG statement.
Static XCF, user-defined IUTSAMEH, or user-defined HiperSockets connectivity between TCP stacks in different TCP subplexes within the same VTAM subplex are not blocked, because you have control over the definition and activation of these connections.
No steps are explicitly taken to block any other network connectivity available through LANs and WANs that might be shared by different subplexes, including scenarios where the same OSA-Express adapter is shared across systems in different subplexes. If complete network isolation between subplexes is required, other mechanisms, such as physical network isolation or logical separation through firewall technologies, should be deployed.
Subplex support applies to TCP/IP and VTAM sysplex functions that make explicit use of XCF communications and coupling facility structures. For TCP/IP, this includes functions such as dynamic XCF, dynamic VIPAs, sysplex distributor, SYSPLEXPORTS, and SWSA. The scope of these functions is typically the entire sysplex. Automated domain name registration (ADNR) does not have explicit support for subplexing, but if ADNR is used in a subplexing environment, the scope of ADNR might be restricted to a subplex when the different subplexes are used to isolate network connectivity. In this case, an instance of ADNR must be started for each subplex in the sysplex that will use ADNR functions. ADNR needs to have affinity to one of the stacks in the subplex when ADNR is started on a system that is running multiple stacks. See adnrproc.sample for an example of the JCL.
In the remainder of this information, references to the sysplex or the sysplex group can refer to the entire sysplex and sysplex group EZBTCPCS, if subplexing is not being used, or to a specific subplex and a specific instance of the sysplex group EZBTvvtt, if subplexing is in effect.