This section describes functions to manage the exceptional conditions that can occur in a transaction-processing network when one system performs an initial or cold start.
CICS Transaction Server for z/OS systems can be started without full recovery in two ways:
On an initial start, all information about both local and
remote resources is erased, and all resource definitions are reinstalled from
the CSD or from CICS tables.
An initial start should be performed only in exceptional circumstances. Examples of times when an initial start is appropriate are:
In CICS TS z/OS, a cold start means that log information about local resources is erased, and resource definitions are reinstalled from the CSD or from CICS tables. However, resynchronization information relating to remote systems or to RMI-connected resource managers is preserved. The CICS log is scanned during startup, and information regarding unit of work obligations to remote systems, or to non-CICS resource managers (such as DB2®) connected through the RMI, is preserved. (That is, any decisions about the outcome of local UOWs, needed to allow remote systems or RMI resource managers to resynchronize their resources, are preserved.)
For guidance information about the different ways in which CICS can be started, see the CICS Recovery and Restart Guide.
At a cold start, information relating to intersystem recovery is read from the system log. Connected systems act as if the local system restarted normally, and resynchronize any outstanding work. Note that updates to local resources that were not fully committed or backed out during the previous run of CICS are not recovered at a cold start, even if the updates were part of a distributed unit of work.
A cold start will not damage the integrity of data if all the following conditions are true:
The cold-started system may or may not contain the same connection definitions that were in use at the previous shutdown. If autoinstalled connections are missing, the remote system may cause them to be recreated, in which case resynchronization takes place. If this does not happen--or if CEDA- or GRPLIST- installed definitions are missing--some action must be taken. See Managing connection definitions.
If you have defined the cold-started system to be part of a VTAM® generic resource group, its connections can be correctly reestablished, provided the affinity relationship maintained by VTAM is still valid. However, the loss of autoinstalled definitions may make it difficult to end VTAM affinities, if this is required. See APPC connections to and from VTAM generic resources.
The DFHRMUTL utility returns information about the type of the last CICS shutdown which is of use in determining whether a cold restart is possible or not. For further details, see the CICS Operations and Utilities Guide.
The protocols that control the communication of syncpointing commit and backout decisions depend on information in the system log. Each time CICS systems connect they exchange tokens called lognames. Lognames are verified during resynchronization; an exchange lognames failure means that the recovery protocol has been corrupted. A failure can take two forms:
"Cold start" is also used in CICS TS z/OS messages and interfaces to describe the action of a partner system that results in a loss of log data for CICS TS z/OS.
However, in CICS TS z/OS, a loss of log data for connected systems is caused by an initial start (not by a cold start), or by a SET CONNECTION NORECOVDATA command.
The exchange lognames process is defined by the APPC architecture. For a full description of the concepts and physical flows, see the SNA Peer Protocols manual. MRO uses a similar protocol to APPC, but there is an important difference: after the erasure of log information at a partner, MRO connections allow new work to begin whatever the condition of existing work, whereas on APPC synclevel 2 sessions no further work is possible until action has been taken to delete any outstanding resynchronization work.
After a partner system has been reconnected, you can use the INQUIRE CONNECTION PENDSTATUS command to check whether there is any outstanding resynchronization work that has been invalidated by the erasure of log information at the partner. A status of 'PENDING' indicates that there is. To check whether APPC connections are able to execute new synclevel 2 work, use the INQUIRE CONNECTION XLNSTATUS command. A status of 'XNOTDONE' indicates that the exchange lognames process has not completed successfully, probably because of a loss of log data.
When CICS detects that a partner system has lost log data, the possible actions it can take are:
When there is outstanding resynchronization work, you can control (for both MRO and APPC connections) which of actions 2 or 3 CICS takes:
The exchange lognames process affects only level 2 synchronization conversations. If it fails, synclevel 2 conversations are not allowed on the link until the failure is resolved by operator action. However, synclevel 0 and synclevel 1 traffic on the link is unaffected by the failure, and continues as normal.