Setting up inter-sysplex communications between generic resources

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.

Establishing connections 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:

  1. On each member of CICSL that is to initiate a connection to CICSR, statically define and install an APPC parallel-session connection in which the NETNAME is the generic resource name of CICSR--that is, define a generic resource name connection. Similarly, on each member of CICSR that is to initiate a connection to CICSL, statically define and install an APPC parallel-session connection in which the NETNAME is the generic resource name of CICSL.
    Note:
    You should not install any predefined connections other than generic resource name connections.

    The first attempt by any member of CICSL to acquire a connection to CICSR (or vice versa) uses a generic resource name connection.

  2. The CICSR member to which VTAM® sends the bind request searches for the generic resource name connection definition for CICSL. (If none exists, it autoinstalls one, subject to the normal rules for autoinstalling connections.)
  3. Subsequent connections that VTAM happens to route to the same member of CICSR from different members of CICSL are autoinstalled on the CICSR member, using the CICSL member name as the NETNAME; that is, CICS autoinstalls member name connections. Similarly, subsequent connections to the same member of CICSL from different members of CICSR are autoinstalled on the CICSL member, using the CICSR member name as the NETNAME. The example in topic Example makes this clearer.

    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.

Example

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.

Figure 32. The figure shows two sysplexes, SYSPLEXL and SYSPLEXR. Each contains a CICS generic resource group. The CICSL1 member of the CICSL group attempts to acquire a connection to a member of the CICSR group in SYSPLEXR.
 The picture shows the flows described in the text. It shows shows two sysplexes, SYSPLEXL and SYSPLEXR. SYSPLEXL contains a generic resource group called CICSL. SYSPLEXR contains a generic resource group called CICSR. This is the first flow: from the CICSL1 member of the CICSL group to the CICSR1 member of the CICSR group in SYSPLEXR. The predefined connections for the generic resource names CICSR and CICSL in CICSL1 and CICSR1 are used.

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. Second flow, CICSL2-CICSR
 The picture shows the flows described in the text. It shows shows two sysplexes, SYSPLEXL and SYSPLEXR. SYSPLEXL contains a generic resource group called CICSL. SYSPLEXR contains a generic resource group called CICSR. This is the second flow: from the CICSL2 member of the CICSL group to the CICSR1 member of the CICSR group in SYSPLEXR. In CICSL2, the predefined connection for CICSR is used. In CICSR1, the predefined connection entry for CICSL is already in use, so a new connection is autoinstalled using the member name CICSL2.

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. Third flow, CICSR1-CICSL
 The picture shows the flows described in the text. It shows shows two sysplexes, SYSPLEXL and SYSPLEXR. SYSPLEXL contains a generic resource group called CICSL. SYSPLEXR contains a generic resource group called CICSR. This is the third flow: from the CICSR1 member of the CICSR group in SYSPLEXR to the CICSL group in SYSPLEXL. The existing affinity forces it to CICSL1.

Figure 34 shows a third flow, this time from CICSR1 to CICSL. The existing affinity forces it to CICSL1.

Figure 35. Fourth flow, CICSR2-CICSL
 The picture shows the flows described in the text. It shows shows two sysplexes, SYSPLEXL and SYSPLEXR. SYSPLEXL contains a generic resource group called CICSL. SYSPLEXR contains a generic resource group called CICSR. This is the fourth flow: from the CICSR2 member of the CICSR group in SYSPLEXR to the CICSL group in SYSPLEXL. It can go to any member of CICSL, but in this example VTAM routes it to CICSL2.

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.

Related tasks
Planning your CICSplex to use VTAM generic resources
Defining connections in a generic resource environment
Generating VTAM generic resource support
Migrating a TOR to a generic resource
Removing a TOR from a generic resource
Moving a TOR to a different generic resource
Ending affinities
Using ATI with generic resources
Using the ISSUE PASS command
Dealing with special cases
Related reference
Prerequisites for VTAM generic resources
Rules checklist

13.
The MAXIMUM option of DEFINE SESSIONS is described in Defining groups of APPC sessions.

[[ Contents Previous Page | Next Page Index ]]