This section describes communications between CICS® Transaction Server for z/OS® generic resources in partner sysplexes. You must use APPC parallel-session connections for links between CICS TS z/OS generic resources.
Assume that you have two sysplexes, SYSPLEXL and SYSPLEXR, and that these contain the CICS TS z/OS generic resource groups CICSL and CICSR, respectively (see Figure 32). The steps involved in establishing connections between CICSL and CICSR are as follows:
The first attempt by any member of CICSL to acquire a connection to CICSR (or vice versa) uses a generic resource name connection.
The template used for autoinstalling these further connections can be any installed connection. CICS uses the generic resource name connection as the default template.
If you decide to use a template other than the default for member name connections, remember that use of the sessions for these connections is initiated by the partner, so consider defining the MAXIMUM option with no contention winners. 13 (This is useful because the member name is not known to the applications in the system in which the member name connection is autoinstalled. They use the GR name for outbound requests. Therefore the member name connection is not used for outbound requests and so does not need to have any sessions defined as winners. By allowing the partner system to have all the sessions as winners, the overhead of bidding for loser sessions is avoided.)
A template is a normal installed connection defined with CONNECTION and SESSIONS that can be used solely as a template, or as a real connection. It is used as a model from which to autoinstall further connections.
In Figure 32 through Figure 35, each generic resource uses the partner sysplex’s generic resource name when initiating a connection. All generic resource members are able to initiate connections; that is, they all have a generic resource name connection (a predefined connection entry in which the NETNAME is the generic resource name of the partner sysplex). The connections are APPC parallel-session synclevel 2 links.
In Figure 32, the first bind that flows from CICSL1 to CICSR is routed to whichever member of CICSR VTAM decides is the most lightly loaded. In this example it goes to CICSR1. The predefined connections for the generic resource names CICSR and CICSL in CICSL1 and CICSR1 are used.
Affinities are created at SYSPLEXL and SYSPLEXR, associating CICSL1 with CICSR1. When you need to end these affinities, you may or may not need to do so explicitly--see Ending affinities and APPC connection quiesce processing. Until the affinities are ended, whenever CICSL1 tries to reconnect to CICSR, VTAM routes the request to CICSR1; and whenever CICSR1 tries to reconnect to CICSL, VTAM routes the request to CICSL1.
Figure 33 shows a bind flow from CICSL2 to CICSR. In this example VTAM has, once again, chosen to route it to CICSR1, but it could have gone to one of the other members of CICSR.
The predefined connection for CICSR in CICSL2 is used. CICSR1 looks for the connection entry for CICSL. It is already in use, so a new connection is autoinstalled using the member name CICSL2.
Affinities are created at SYSPLEXL and SYSPLEXR, associating CICSL2 with CICSR1. If you need to end these affinities, you may or may not need to do so explicitly.
Figure 34 shows a third flow, this time from CICSR1 to CICSL. The existing affinity forces it to CICSL1.
Figure 35 shows a fourth flow, this time from CICSR2 to CICSL. It can go to any member of CICSL, but in this example VTAM routes it to CICSL2.
The predefined connection entry for CICSL in CICSR2 is not in use and so it is used now. CICSL2 looks for the predefined connection entry for CICSR. It is in use, and so an entry for CICSR2 is autoinstalled.
Affinities are created at SYSPLEXL and SYSPLEXR, associating CICSL2 with CICSR2. If you need to end these affinities, you may or may not need to do so explicitly.