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:
All file control state data and resource definitions are recovered in the same way as on a warm start (see Files).
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.
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.
As for warm restart (see Recreating non-RLS retained locks).
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.
Recovery of transient data is the same as for a warm start, with the following exceptions:
As for warm restart (see Transactions).
As for warm restart (see Programs).
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.
As for warm restart (see Monitoring and statistics).
As for warm restart (see Journal names and journal models).
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.
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.
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.
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.
As for warm restart (see URIMAP definitions and virtual hosts).
[[ Contents Previous Page | Next Page Index ]]