Rebuilding the CICS state after an abnormal termination

The individual resource managers (such as file control) and the CICS® domains are responsible for recovering their state as it was at an abnormal termination. The process of rebuilding their state is much the same as for a warm restart. This topic discusses the process of rebuilding their state from the catalogs and system log, describing the differences between a warm and emergency restart, in terms of the following resources:

Files

All file control state data and resource definitions are recovered in the same way as on a warm start (see Files).

Reconnecting to SMSVSAM for RLS access

As on a warm restart, CICS connects to the SMSVSAM server. In addition to notifying CICS about lost locks, VSAM also informs CICS of the units of work belonging to the CICS region for which it holds retained locks. See Lost locks recovery for information about the lost locks recovery process for CICS.

CICS uses the information it receives from SMSVSAM to eliminate orphan locks.

RLS restart processing and orphan locks

CICS emergency restart performs CICS-RLS restart processing during which orphan locks are eliminated. An orphan lock is one that is held by VSAM RLS on behalf of a specific CICS but unknown to the CICS region, and a VSAM interface enables CICS to detect UOWs that are associated with such locks.

Orphan locks can occur if a CICS region acquires an RLS lock, but then fails before logging it. Records associated with orphan locks that have not been logged cannot have been updated, and CICS can safely release them.

Note:
Locks that fail to be released during UOW commit processing cause the UOW to become a commit-failed UOW. CICS automatically retries commit processing for these UOWs, but if the locks are still not released before the CICS region terminates, these also are treated as orphan locks during the next restart.

Recreating non-RLS retained locks

As for warm restart (see Recreating non-RLS retained locks).

Temporary storage

Auxiliary temporary storage queue information for recoverable queues only is retrieved from the warm keypoint. The TS READ pointers are not recovered and are set to zero.

If a nonzero TSAGE parameter is specified in the temporary storage table (TST), all queues that have not been referenced for this interval are deleted.

Transient data

Recovery of transient data is the same as for a warm start, with the following exceptions:

Transactions

As for warm restart (see Transactions).

Programs

As for warm restart (see Programs).

Start requests

In general, start requests are recovered if, and only if:

Recovery can, however, be further limited by the use of the specific COLD option on the system initialization parameter for TS, ICP, or BMS. If you suppress start requests by means of the COLD option on the appropriate system initialization parameter, any data associated with the suppressed starts is discarded. The rules are:

Start requests that have not been suppressed for any of the above reasons either continue to wait if their start time or interval has not yet expired, or are processed immediately.

For start requests with terminals, consider the effects of the CICS restart on the set of installed terminal definitions. For example, if the terminal specified on a start request is no longer installed after the CICS restart, CICS invokes an XALTENF global user exit program (if enabled), but not the XICTENF exit.

Monitoring and statistics

As for warm restart (see Monitoring and statistics).

Journal names and journal models

As for warm restart (see Journal names and journal models).

Terminal control resources

Terminal control information is installed from the warm keypoint in the global catalog, or installed from the TCT, depending on whether the definitions are CSD-defined or TCT-defined.

CSD-defined resource definitions

CICS retrieves the state of the CSD-eligible terminal control resources from the catalog entries that were written:

The state of the catalog may have been modified for some of the above resources by their removal with a CEMT, or an EXEC CICS DISCARD, command.

CICS uses records from the system log, written when any terminal resources were being updated, to perform any necessary recovery on the cataloged data. This may be needed if terminal resources are installed or deleted while CICS is running, and CICS fails before the operation is completed.

Some terminal control resources are installed or deleted in "installable sets" as described under Committing and cataloging resources installed from the CSD. If modifications are made to terminal resource definitions while CICS is running, CICS writes the changes in the form of forward recovery records to the system log. If the installation or deletion of installable sets or individual resources is successful, but CICS abnormally terminates before the catalog can be updated, CICS recovers the information from the forward recovery records on the system log.

If the installation or deletion of installable sets or individual resources is unsuccessful, or has not reached commit point when CICS abnormally terminates, CICS does not recover the changes.

In this way, CICS ensures that the terminal entries recovered at emergency restart consist of complete logical sets of resources (for connections, sessions, and pipelines), and complete terminal resources and autoinstall models, and that the catalog reflects the real state of the system accurately.

TCAM and sequential (BSAM) devices

CICS installs TCAM and sequential terminal resource definitions from the TCT. Because there is no warm keypoint if the previous run terminated abnormally, the TCT cannot be modified as on a warm start. Whatever is defined in the TCT is installed, and the effect is the same whether or not it is a different TCT from the last run.

Note:
Start of change
CICS TS 3.1 supports only remote TCAM terminals. That is, the only TCAM terminals you can define are those attached to a remote, pre-CICS TS 3.1, terminal-owning region by TCAM/DCB.
End of change

Distributed transaction resources

CICS retrieves its logname from the recovery manager control record in the global catalog for use in the "exchange lognames" process with remote systems. Resynchronization of in-doubt units of work takes place when CICS completes reconnection to remote systems.

See the CICS Intercommunication Guide for information about recovery of distributed units of work.

URIMAP definitions and virtual hosts

As for warm restart (see URIMAP definitions and virtual hosts).

[[ Contents Previous Page | Next Page Index ]]