CICS warm restart
If you specify START=AUTO, which is the recommended method, CICS® determines which
type of start to perform using information retrieved from the recovery manager's control record in
the global catalog. If the type-of-restart indicator in the control record indicates warm start
possible
, CICS
performs a warm restart. For a warm start to succeed, CICS needs the information stored in the CICS catalogs at the
previous shutdown, and the information stored in the system log. This section describes the CICS startup processing
specific to a warm restart.
emergency restart needed, CICS performs an emergency restart. See CICS emergency restart for the restart processing performed.
CICS warm restart action summary
- Restores the state of the CICS region to the state it was in at completion of the normal shutdown. All
CICS resource
definitions are restored from the global catalog, and the GRPLIST,
FCT, and CSD system initialization parameters are ignored.
CICS also uses information from the warm keypoint in the system log. A warm start restores certain elements of the CICS components to the status that was recorded in the previous warm keypoint. The recorded status is determined from their definitions or commands rather than their actual status at shutdown.
- Reconnects to the system log.
- Retries any backout-failed and commit-failed units of work.
- Rebuilds indoubt-failed units of work.
See also CICS actions on a warm start.
How CICS rebuilds its state after a normal shutdown
During a warm restart, CICS initializes using information from the catalogs and system log to restore the region to its state at the previous normal shutdown.
CICS needs both the catalogs and the system log from the previous run of CICS to perform a warm restart — the catalogs alone are not sufficient. If you run CICS with the system log defined as TYPE(DUMMY), CICS appears to shut down normally, but only the global catalog portion of the warm keypoint is written. Therefore, without the warm keypoint information from the system log, CICS cannot perform a warm restart. CICS startup fails unless you specify an initial start with START=INITIAL.
It is the responsibility of the individual resource managers (such as file control) and the CICS domains to recover their own state. The rebuilding process for resources varies depending on the type of resource, and whether or not the resource was defined as part of a CICS bundle.
What happens to various CICS resources during a warm restart
The following information provides more detail about what happens to different CICS resources during a warm restart.
| Resources | Description |
|---|---|
| Files | File control information from the previous run is recovered from information recorded in the CICS catalog only. File resource definitions for VSAM and BDAM files, data tables, and LSR pools are installed from the global catalog, including any definitions that were added dynamically during the previous run. The information recovered and reinstalled in this way reflects the state of all file resources at the previous shutdown. For further details, see Files. |
| Temporary storage |
Auxiliary temporary storage queue information (for both recoverable and non-recoverable queues) is retrieved from the warm keypoint. Note that TS READ pointers are recovered on a warm restart (which is not the case on an emergency restart). CICS opens the auxiliary temporary storage data set for update. Any queues written to a shared temporary storage pool, even though non-recoverable, persist across a warm restart. |
| Transient data | See Transient data. |
| Transactions | All transaction and transaction class resource definitions are installed from the CICS system definition data set (CSD), and updated with information from the warm keypoint in the system log. The resource definitions installed from the catalog include any that were added dynamically during the previous run. |
| Distributed transaction resources | CICS retrieves
its logname from the recovery manager control record in the global catalog for use in the
exchange lognamesprocess with remote systems. Resynchronization of indoubt units of work takes place after CICS completes reconnection to remote systems. See Recovery functions and interfaces for information about recovery of distributed units of work. |
| LIBRARY | All LIBRARY definitions will be restored from the catalog, and the actual search order through the list of LIBRARY resources that was active at the time of the preceding shutdown will be preserved. For further details, see LIBRARY resources. |
| Programs | The recovery of program, mapset, and partitionset resource definitions depends on whether you are using program autoinstall and, if you are, whether you have requested autoinstall cataloging (specified by the system initialization parameter PGAICTLG=ALL|MODIFY). See Programs. |
| START requests | In general, start requests are recovered together with any associated start data. Recovery can, however, be suppressed for temporary storage, interval control, or basic mapping support. See Start requests. |
| Monitoring and statistics | The CICS monitoring and statistics domains retrieve their status from their control records stored in the global catalog at the previous shutdown. This is modified by any runtime system initialization parameters. |
| Journal names and journal models | The CICS log manager restores the journal name and journal model definitions from the global catalog. Journal name entries contain the names of the log streams used in the previous run, and the log manager reconnects to these during the warm restart. |
| Terminal control resources | Terminal control information is installed from the warm keypoint in the global catalog, or installed from the terminal control table (TCT), depending on whether the resources are CSD-defined or TCT-defined. See Terminal control resources. |
| URIMAP definitions and virtual hosts | Installed URIMAP definitions for CICS Web support are restored from the global catalog, including their enable status. Virtual hosts, which are created by CICS using the host names specified in installed URIMAP definitions, are also restored to their former enabled or disabled state. |
| Resources in bundles | These resources have no definition, are not stored in the catalog, and are recovered through the application or platform. See Recovery of resources in bundles. |