This section describes some special cases that you may need to consider. Note that much of the information applies only to links to back-level systems--where, for example, you are initiating a connection to a non-CICS® TS z/OS® system. For connections between CICS TS z/OS generic resources, much of the following information can be disregarded.
Because members of a generic resource should be functionally equivalent, it is not recommended that you should predefine terminals to specific members of a generic resource. Use autoinstall instead, and allow VTAM® to balance the TORs’ workload dynamically. However, there may be times--for example, while you are migrating an existing TOR into a generic resource--when it is necessary to use static definitions.
If an LU is predefined to a specific terminal-owning region, and the LU initiates the connection (that is, it sends the first bind request) using the TOR’s generic resource name, the generic resource function must make the connection to the "correct" terminal-owning region--the one that has the definition. This requirement means that you must install the VTAM generic resource resolution exit program, ISTEXCGR, to enforce selection of the correct applid (for the terminal-owning region).
Note that this is not necessary if the connection is always initiated by the terminal-owning region (by means, for example, of a START request).
A sample ISTEXCGR exit program is supplied with VTAM 4.2. For details, see the OS/390 eNetwork Communications Server: SNA Customization manual.
This section discusses outbound LU6 connections from TORs that are members of a generic resource group. By "outbound" we mean connections to systems outside the CICSplex.
For LU6 connections initiated by a generic resource member, where the partner is not itself a CICS Transaction Server for z/OS generic resource, the partner must know the member TOR by its generic resource name.
The requirement therefore applies when a generic resource member initiates any of the following kinds of connection:
Because (unless the partner is also a CICS TS z/OS generic resource) an attempt by a generic resource member to connect to an LU6 partner will succeed only if the partner knows the TOR by its generic resource name, it follows that the partner can accept a connection to only one member of the generic resource at a time. In a configuration in which more than one member of a generic resource must connect to a remote system, you can choose a region within the CICSplex to act as a network hub. This means that all generic resource members daisy-chain their requests for services from remote systems through the hub.
The network hub can be a member of the generic resource, in which case it is necessary to install a VTAM generic resource resolution exit program to direct any incoming binds from LU6 partners that know us by our generic resource name to the network hub region.
An alternative solution is to have a network hub that is not a member of the generic resource. This avoids the need for the VTAM generic resource resolution exit program, but requires that LU6 partners that may initiate connections to the CICSplex log on using the applid of the network hub region.
Figure 37 shows a network hub that is not a member of the generic resource.
In Figure 37, the regions in CICSplex CIC1 are connected by MRO links. The terminal-owning regions T1, T2, and T3 are members of the generic resource group, CICSG, but the hub TOR, H, is not. H has an LU6.1 or APPC connection to the remote region, R. The TORs daisy-chain their requests to R through H.