Initial and cold starts

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.

Important

CICS Transaction Server for z/OS systems can be started without full recovery in two ways:

Initial start
An initial start may be performed in either of the following circumstances:

Start of changeOn 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. End of change

An initial start should be performed only in exceptional circumstances. Examples of times when an initial start is appropriate are:

Cold start
A cold start may be performed in either of the following circumstances:

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.

Deciding when a cold start is possible

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:

  1. Either
  2. Attached resource managers that use the RMI are subsequently reconnected to allow resynchronization.
  3. Connections to remote systems required for resynchronization are subsequently acquired.

    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 exchange lognames process

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:

  1. A cold/warm log mismatch. A cold/warm log mismatch is caused by the loss of log data at one partner when the other has resynchronization work outstanding.
    Note:
    The term "cold start" is used in the SNA Peer Protocols manual, and by other products that communicate with CICS TS z/OS to describe the cause of a loss of log data.

    "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.

  2. A lognames mismatch. A lognames mismatch is caused by a corruption of logname data. This can occur due to:
    1. A system logic error
    2. An operational error--for example, a failure to perform an initial start when migrating from a back-level CICS release to CICS Transaction Server for z/OS.

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:

  1. None. If there is no resynchronization work outstanding on the local system, the loss of log data has no effect.
  2. Keep outstanding resynchronization work (which may include UOWs which were in-doubt when communication was lost) for investigation.
  3. Delete outstanding resynchronization work; any in-doubt UOWs are committed or backed out according to the ACTION option of the associated transaction definition, and any decisions remembered for the partner are forgotten.

When there is outstanding resynchronization work, you can control (for both MRO and APPC connections) which of actions 2 or 3 CICS takes:

Considerations for APPC connections

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.

Related concepts
Syncpoint exchanges
Recovery functions and interfaces
Connections that do not fully support shunting
APPC connection quiesce processing
Related tasks
Managing connection definitions
Problem determination
Related reference
Terminology
[[ Contents Previous Page | Next Page Index ]]