Rebuilding the CICS 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.

Note:
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 actually 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.

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:

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 example:

Note:
An exception to the above rule occurs when there are updates to a file to be backed out during restarts, in which case the file is opened regardless of the OPENTIME option. At a warm start, there cannot be any in-flight units of work to back out, so this backout can only occur when retrying backout-failed units of work against the file.

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

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.

Reconnecting to SMSVSAM for RLS access

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.

Recreating non-RLS retained locks

For non-RLS files, the CICS enqueue domain rebuilds the retained locks relating to shunted units of work.

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.

Temporary storage data sharing server

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

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:

TDINTRA=NOEMPTY (the default)

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.

Note:
If, during the period when CICS is installing the TD queues, an attempt is made to write a record to a CICS-defined queue that has not yet been installed (for example, CSSL), CICS writes the record to the CICS-defined queue CXRF.

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.

Trigger levels (for TERMINAL and SYSTEM only)

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

TDINTRA=EMPTY

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.

Transactions

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.

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

No autoinstall for programs

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.

Autoinstall for programs

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:

Start requests

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.

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 run-time 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 TCT, depending on whether the resources are CSD-defined or TCT-defined.

CSD-defined resource definitions

CICS installs the following terminal control resource definitions from the global catalog:

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.

TCAM and sequential (BSAM) devices

CICS installs TCAM and sequential terminal resource definitions as follows:

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 after CICS completes reconnection to remote systems.

See the CICS Recovery and Restart Guide for information about recovery of distributed units of work.

Start of change

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.

End of change [[ Contents Previous Page | Next Page Index ]]