This section describes how to manage definitions of MRO and APPC parallel-session connections between CICS® Transaction Server for z/OS® systems. For considerations that apply to other types of connection, see Connections that do not fully support shunting.
Recovery information for a remote system is largely independent of the connection definition for the system. This allows you to manage (for example, modify) connection definitions independently of any recovery information that may be outstanding. However, in some cases the connection definition holds important information, which means that it must be kept, unmodified, until any recovery between the systems is complete.
For connections to other CICS Transaction Server for z/OS systems, the connection definition contains no recovery information. You can modify connections without regard to recovery, provided that the netname of the connection remains the same.
If a connection definition is lost at a cold start, use the CEMT INQUIRE UOWLINK RESYNCSTATUS(UNCONNECTED) command to discover whether CICS retains any recovery information for the previously-connected system. This command will tell you whether CICS contains any tokens (UOW-links) associating UOWs with the lost connection definition. If there are UOW-links present, you can either:
You can use the same commands if a connection has been discarded.
APPC parallel-session connections in a CICS Transaction Server for z/OS system that is not registered as a member of a VTAM® generic resource contain no recovery information and can be managed in the same way as MRO connections to CICS TS z/OS systems.
If CICS is a member of a VTAM generic resource group, the local VTAM may have an affinity which directs any new binds from a partner to this same local system. You must not end the affinity held by VTAM if there is any possibility that resynchronization with the partner may be needed; if you do, binds (and subsequent resynchronization messages) may be directed to a different member of the generic resource. In most cases, it is safest to allow the APPC connection quiesce protocol to end the affinities automatically--see APPC connection quiesce processing.
CICS prevents the execution of the SET CONNECTION ENDAFFINITY command if a logname has been received from the partner system, because this is the condition under which the partner may begin recoverable work and start resynchronization. The discarding of a connection is also prevented, because its loss means that the logname is no longer visible. If you intend ending affinities, you should do it before shutting down CICS prior to a cold start, because a cold start restores a logname without the associated connection. Ending affinities without removing the logname can cause exchange logname failures later.
For further information about affinities and how to end them, see Ending affinities.
For members of a generic resource, the connection definition is the only way (using the INQUIRE and SET CONNECTION RECOVSTATUS commands) of safely managing lognames and affinities. Connections can be discarded only if their recovery status (RECOVSTATUS) is NORECOVDATA. You can use the SET CONNECTION RECOVSTATUS command to set a connection’s recovery status to NORECOVDATA if neither the local system nor the partner has any in-doubt units of work dependent on the other. A simple and safe test is that neither system’s connection to the other should have a status of RECOVSTATUS(RECOVDATA). If this test succeeds, you can issue SET CONNECTION NORECOVDATA on both, and SET CONNECTION ENDAFFINITY on the generic resource members.