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.
Recovering their own state is the responsibility of the individual resource managers (such as file control) and the CICS domains. This topic discusses the process of rebuilding their state from the catalogs and system log, in terms of the following resources:
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 example:
CICS closes all files at shutdown, and, as a general rule, you should expect your files to be re-installed on restart as either:
The FCT and the CSDxxxx system initialization parameters are ignored.
File control uses the system log to reconstruct the internal structures, which it uses for recovery.
Data set name blocks (DSNBs), one for each data set opened by CICS file control, are recovered during a warm restart. If you have an application that creates many temporary data sets, with a different name for every data set created, it is important that your application removes these after use. If applications fail to get rid of unwanted name blocks they can, over time, use up a considerable amount of CICS dynamic storage. See the CICS System Programming Reference for information about using the SET DSNAME REMOVE command to remove unwanted data set name blocks.
CICS connects to the SMSVSAM server, if present, and exchanges RLS recovery information. In this exchange, CICS finds out whether SMSVSAM has lost any retained locks while CICS has been shut down. This could happen, for example, if SMSVSAM could not recover from a coupling facility failure that caused the loss of the lock structure. If this has happened, CICS is notified by SMSVSAM to perform lost locks recovery. See Lost locks recovery for information about this process.
For non-RLS files, the CICS enqueue domain rebuilds the retained locks relating to shunted units of work.
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.
Shared TS pools are managed by a temporary storage server and stored in the coupling facility. Stopping and restarting a TS data sharing server does not affect the contents of the TS pool, unless you clear the coupling facility structure in which the pool resides.
Transient data initialization on a warm restart depends on the TDINTRA system initialization parameter, which specifies whether or not TD is to initialize with empty intrapartition queues. The different options are discussed as follows:
All transient data resource definitions are installed from the global catalog, including any definitions that were added dynamically during the previous run. TD queues are always installed as enabled.
CICS opens any extrapartition TD queues that need to be opened--that is, any that specify OPEN=INITIAL.
The recovery manager returns log records and keypoint data associated with TD queues. CICS applies this data to the installed queue definitions to return the TD queues to the state they were in at normal shutdown. Logically recoverable, physically recoverable, and non-recoverable intrapartition TD queues are recovered from the warm keypoint data.
After the queues have been recovered, CICS checks the trigger level status of each intrapartition TD queue that is defined with FACILITY(TERMINAL|SYSTEM) to determine whether a start request needs to be rescheduled for the trigger transaction. If a trigger transaction failed to complete during the previous run (that is, did not reach the empty queue (QZERO) condition) or the number of items on the queue is greater than the trigger level, CICS schedules a start request for the trigger transaction.
This does not apply to trigger transactions defined for queues that are associated with files (FACILITY(FILE)).
The transient data queues are 'cold started', but the resource definitions are 'warm started':
This option is intended for use when initiating remote site recovery (see CICS emergency restart), but you can also use it for a normal warm restart. For example, you might want to 'cold start' the intrapartition queues when switching to a new data set if the old one is corrupted, while preserving all the resource definitions from the catalog.
You cannot specify a general cold start of transient data while the rest of CICS performs a warm restart, as you can for temporary storage.
All transaction and transaction class resource definitions are installed from the 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.
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).
If program autoinstall is disabled (PGAIPGM=INACTIVE), all program, mapset, and partitionset resource definitions are installed from the 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.
If program autoinstall is enabled (PGAIPGM=ACTIVE), program, mapset, and partitionset resource definitions are installed from the CSD only if they were cataloged; otherwise they are installed at first reference by the autoinstall process. All definitions installed from the CSD are updated with information from the warm keypoint in the system log.
CICS catalogs program, mapset, and partitionset resource definitions as follows:
In general, start requests are recovered together with any associated start data. Recovery can, however, be suppressed by specifying explicit cold start system initialization parameters for temporary storage, interval control, or basic mapping support (on the TS, ICP, and BMS system initialization parameters respectively). Any data associated with suppressed starts is discarded.
The rules governing the operation of the explicit cold requests on system initialization parameters 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 they 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.
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 run-time system initialization parameters.
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 information is installed from the warm keypoint in the global catalog, or installed from the TCT, depending on whether the resources are CSD-defined or TCT-defined.
CICS installs the following terminal control resource definitions from the global catalog:
Apart from the above, autoinstalled terminals are not recovered, because they are removed from the warm keypoint during normal shutdown. This ensures that their definitions are installed only when terminal users next log on after a CICS restart that follows a normal shutdown.
Only the global catalog is referenced for terminals defined in the CSD.
To add a terminal after initialization, use the CEDA INSTALL or EXEC CICS CREATE command, or the autoinstall facility. To delete a terminal definition, use the DISCARD command or, if autoinstalled, allow it to be deleted by the autoinstall facility after the interval specified by the AILDELAY system initialization parameter.
CICS installs TCAM and sequential terminal resource definitions as follows:
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 after CICS completes reconnection to remote systems.
See the CICS Recovery and Restart Guide for information about recovery of distributed units of work.
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.