Ensuring consistency across the IMSplex

Inconsistencies in definitions, operator commands and procedures, and exit routines can create problems within a generic resource group.

At a minimum, they can confuse terminal users, who are unaware of being in session with different IMS systems from one logon to another logon.
At worst, they can cause processing disruptions.

Restriction: LU6.1 parallel sessions between IMS and another node must all use VGR or non-VGR. LU6.1 parallel VGR and non-VGR sessions (ISC or MSC) cannot be mixed because the first parallel session established between the LU6.1 partners establishes how the partner node is known, by either the real APPLID name (non-VGR) or the GRSNAME (VGR). This condition is remembered by VTAM®, and VTAM sets a flag (INRIFLG0 = NIBNNAMS in the ISTNRIPL parameter area) on subsequent parallel session initiations to indicate this name association. IMS uses this flag to establish the session. The mismatch could cause the session initiation to fail (such as DFS3645 Logon Rejected) or the session affinity to be incorrectly managed by IMS.

You can mix VGR and non-VGR between non-parallel LU6.1 sessions, such as simultaneous use of IMS1 to IMS2 using VGR, IMS1 to CICS® using non-VGR, or IMS1 to IMS3 using non-VGR.

Recommendations: To ensure consistency across a generic resource group:

Use equivalent specifications when defining the member IMS systems.
Example: If one IMS specifies that ETO be included (ETOFEAT=YES on the IMSCTRL macro), all other IMS systems in the generic resource group should specify that ETO be included.
Specify execution parameters consistently across generic resource members.
Example: IMS systems in a generic resource group should each specify that ETO be enabled or not be enabled.
If ETO is included, specify the same information on the ETO descriptors for each IMS generic resource group member.
Use the same naming conventions for LTERMs and transactions across a generic resource group. If the same LTERM name is assigned to different nodes on different IMS systems, unpredictable results might occur.
Related Reading: For more information about how to ensure name uniqueness and resource type consistency, see Planning for Transaction Manager resources in an IMSplex.
Make all terminal definitions consistent across generic resource members.
Example: LTERM names should be consistently defined, during IMS system definition, to the same physical terminals on all the IMS systems in the generic resource group.
MSC links in a generic resource group should be cloned.
Example: Generic resource groups should have the same MSPLINK, MSLINK, and MSNAME characteristics
Ensure that master terminal operators (MTOs) on each IMS in the generic resource group have procedures for notifying the other MTOs about the commands they issue. If you are using a single point of control (SPOC), commands go to all IMS systems that can process the commands and there is no need for the notification procedures.
Example: If you do not have Resource Manager (RM) and one MTO issues a /STOP command to stop a user on one IMS in a generic resource group, that user is stopped only on the IMS on which /STOP is entered. If you have RM and a resource structure, however, RM manages the user globally and the user is stopped on all the IMS systems in the IMSplex.

Related reading: For more information on using a SPOC, see Controlling IMS with the TSO SPOC application in IMS Version 15.3 Operations and Automation.
Make exit routines functionally equivalent across a generic resource group—especially the Destination Creation exit routine, the OTMA Routing exit routines, the Logon and Signon exit routines, and the Logoff and Signoff exit routines.