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:
v If you manually set a file closed (which changes its status to UNENABLED) and
perform a normal shutdown, it remains UNENABLED after the warm restart.
v Similarly, if you set a file DISABLED, it remains DISABLED after the warm
restart.
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:
v OPEN and ENABLED if the OPENTIME option is STARTUP
v CLOSED and ENABLED if the OPENTIME option is FIRSTREF.
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” on page 89 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.
54 CICS TS for z/OS 4.1: Recovery and Restart Guide