This section describes how to manage existing terminals and connections
when migrating a TOR to membership of a CICS® Transaction Server for z/OS® generic resource. How to
establish connections between two CICS TS z/OS generic
resources is described separately in Setting up inter-sysplex communications between generic resources.
Note:
For the purposes of this discussion, a "terminal-owning
region" is any CICS region that owns terminals and is a candidate to be
a member of the generic resource.
In general, we advise that:
- For simplicity, you first create a generic resource consisting of only
one member. Do not add further members until the single-member generic resource
is functioning satisfactorily.
- Because all members of a generic resource should be functionally equivalent,
you create additional members by cloning the first member. (A situation in
which you might choose to ignore this advice is described below.)
There are two recommended methods for migrating a TOR to a generic resource.
Which you use depends on whether there are existing LU6 connections.
No LU6 connections
If there are no LU6 (that is, APPC or LU6.1) connections to your terminal-owning
region, we recommend that you choose a new name for the generic resource and
retain your old applid. Non-LU6 terminals can log on by either applid or generic
resource name, hence they are not affected by the introduction of the generic
resource name. You can then gradually migrate the terminals to using the generic
resource name. Later, you can expand the generic resource by cloning the first
member-TOR.
Note:
If you have several existing TORs that are functionally similar,
rather than cloning the first
member you might choose to expand the generic resource by adding these existing
regions, using their applids as member-names.
LU6 connections
If there are LU6 (APPC or LU6.1) connections to your terminal-owning region12 ,
we recommend that they log on using the generic resource name. However, you
will probably want to migrate to generic resource without requiring all your
LU6 network partners to change their logon procedures. One option is to use
the applid of your existing terminal-owning region as the new generic resource
name. Because this requires you to choose a new applid, it is also necessary
to change the CONNECTION definitions of MRO-connected application-owning regions
and RACF® profiles that specify the old applid. Note, however, that you do
not need to change the APPL profile to which the users are authorized--CICS
passes the GRNAME to RACF as the APPL name during signon validation, and the
old applid is now the GRNAME. The recommended migration steps are:
- Configure your CICSplex with a single terminal-owning region.
- Set the generic resource name to be the current applid of that terminal-owning
region.
- Change the current applid to a new value.
- Change CONNECTION definitions in MRO partners to use the new applid for
the terminal-owning region.
- Change RACF profiles that specify the old applid.
- Restart the CICSplex.
At this point:
- Non-LU6 terminals can log on using the old name (without being aware that
they are now using a VTAM® generic resource). They will, of course, be connected
to the same TOR as before because there is only one in the generic resource
set.
- LU6 connections log on using the old name (thereby conforming to the recommendation
that they should connect by generic resource name).
- Install new cloned terminal-owning regions with the same generic resource
name and the same connectivity to the set of AORs.
At this point:
- Autoinstalled non-LU6 terminals start to exploit session balancing.
- Autoinstalled APPC sync level 1 connections start to exploit session balancing.
- Because of affinities, existing LU6.1 and APPC sync level 2 connections
continue to be connected to the original terminal-owning region (by generic
resource name).
- Special considerations apply to non-autoinstalled terminals and connections,
and to LU6 connections used for outbound requests. These are described in Dealing with special cases.

Not counting connections to other members of the generic resource.
[[ Contents Previous Page | Next Page Index ]]