Recovery for files

A CICS® file is a logical view of a physical data set, defined to CICS in a file resource definition with an 8-character file name. A CICS file is associated with a VSAM or BDAM data set by one of the following:

More than one file can refer to the same data set.

A data set is defined to be the physical object residing on DASD. It has a 44-character DSNAME. A VSAM data set, for example, is defined using VSAM access method services (AMS).

When designing your applications, ensure that application data is protected from transaction failures that could lead to data corruption, and that you can recover from accidental damage to storage devices.

When deciding on the access method, consider the recovery and restart facilities provided by each. These considerations are discussed in the following topics.

VSAM files

CICS file control supports three VSAM access modes--local shared resources (LSR), non-shared resources (NSR), and record-level sharing (RLS). This topic discusses recovery considerations for VSAM files accessed in these modes.

Sharing data sets with batch jobs

Sharing data sets directly between online CICS update transactions and batch update programs using VSAM share options (where available) or job control sharing is not recommended for non-RLS access modes. Sharing risks the integrity of the data with the result that application programs may appear to function correctly, but with incorrect data. Such loss of data integrity can occur, for example, if a CICS unit of work updates a record that is later updated by a non-CICS job while the CICS unit of work is still running. If the CICS unit of work abends, CICS backs out the record to the value it had at the start of the CICS unit of work, thus destroying the update from the non-CICS job.

File-owning regions and RLS access

To share data sets between more than one CICS region, use the RLS access mode or use a file-owning region (FOR) with function shipping from the application-owning regions (AORs). From a recovery point of view, RLS does not create distributed units of work, as happens between the AOR and FOR, because files accessed in RLS mode are all regarded as local to each CICS region. The SMSVSAM server takes the place of the FOR. However, there are special recovery considerations for data sets accessed in RLS mode, in connection with the role of SMSVSAM and its lock management.

Forward recovery

For VSAM files, you can use a forward recovery utility, such as CICSVR, when online backout processing has failed as a result of some physical damage to the data set. For forward recovery:

Backward recovery

To ensure that VSAM files can be backward recoverable, certain points should be considered:

Basic direct access method (BDAM)

CICS does not support forward recovery for BDAM files. You can implement your own forward recovery support using automatic journaling options.

Backout for BDAM data sets is the same as for ESDS data sets in that you cannot delete records from the data set.

Defining files as recoverable resources

This section describes how to define the recovery attributes for files managed by CICS file control.

You specify recovery options, including forward recovery, either in the integrated catalog facility (ICF) catalog (if you are using DFSMS 1.3 or later), or in the CICS file resource definition, as follows:

VSAM files accessed in non-RLS mode

You can specify support for both forward and backward recovery for VSAM files using the RECOVERY and FWDRECOVLOG options. You define the type of data set backup you want using the BACKUPTYPE parameter.

RECOVERY(ALL)
If you specify RECOVERY(ALL), CICS provides both forward and backout recovery for the file. Using the services of the CICS recovery manager and log manager, CICS file control writes:

CICS forward recovery support is totally independent of automatic journaling. However, autojournal records, which are controlled by the JOURNAL and associated JNLxxx options on the file resource definition, can be written to the same general log stream as forward recovery data. To do this, specify on the JOURNAL option a journal identifier that maps to the same forward recovery log stream. See the CICS System Definition Guide for information about mapping CICS journal identifiers to log streams through journal model resource definitions.

Note:
The use of autojournal records for forward recovery purposes is not recommended for VSAM files.
RECOVERY(BACKOUTONLY)
If you specify RECOVERY(BACKOUTONLY), CICS provides backout recovery only, writing only before-images to the system log.
BACKUPTYPE(DYNAMIC)
If you specify BACKUPTYPE(DYNAMIC), CICS supports the DFSMS backup-while-open (BWO) facility, enabling the data set to be backed up while open. If you specify STATIC, all CICS files open against a data set must be closed before it can be backed up. For information about the backup-while-open (BWO) facility, see Backup-while-open (BWO).

VSAM files accessed in RLS mode

If you specify file definitions that open a data set in RLS mode, specify the recovery options in the ICF catalog. The recovery options on the CICS file resource definitions (RECOVERY, FWDRECOVLOG, and BACKUPTYPE) are ignored if the file definition specifies RLS access.

The VSAM parameters LOG and LOGSTREAMID, on the access methods services DEFINE CLUSTER and ALTER commands, determine recoverability for the entire sphere. Locating these recovery parameters in the ICF catalog enforces the same options, for all CICS regions in the sysplex, for all the files opened against a given sphere.

LOG({NONE|UNDO|ALL})
Specifies the type of recovery required for the VSAM sphere. Specify the LOG parameter for data sets that are to be used by CICS in RLS mode.
NONE
The sphere is not recoverable.
UNDO
The sphere is recoverable. CICS must maintain system log records for backout purposes.
ALL
The sphere is recoverable for both backout and forward recovery. CICS must maintain system log records (as for UNDO) and forward recovery log records. If you specify LOG(ALL), also specify LOGSTREAMID to indicate the name of the forward recovery log.
Note:
Forward recovery support is available for recoverable files only--you cannot have forward recovery without backout recovery.
LOGSTREAMID(log_stream_name)
Specifies the name of the log stream to be used for forward recovery log records when LOG(ALL) is defined. Note that IDCAMS does not check for the presence of the LOGSTREAMID during DEFINE processing. CICS checks for a log stream name when attempting to open a data set defined with LOG(ALL), and the open fails if the log stream is not defined and cannot be created dynamically.

If you omit the LOG parameter when defining your VSAM data sets, recovery is assumed to be UNDEFINED, and the data set cannot be opened in RLS mode. You can also set the UNDEFINED status explicitly by specifying NULLIFY(LOG).

For information about the access methods services DEFINE and ALTER commands, see DFSMS/MVS Access Method Services for ICF, SC26-4906, and DFSMS/MVS Using Data Sets, SC26-4922.

Inquiring on recovery attributes

You can use CEMT, or EXEC CICS, INQUIRE FILE and INQUIRE DSNAME commands to determine the recovery options that are specified for files and data sets. The INQUIRE FILE command shows the options from the CICS file definition until the first file for the data set is opened. If the options are obtained from the ICF catalog when the first file is opened, the ICF catalog values are returned. The INQUIRE DSNAME command returns values from the VSAM base cluster block (BCB). However, because base cluster block (BCB) recovery values are not set until the first open, if you issue an INQUIRE DSNAME command before the first file is opened, CICS returns NOTAPPLIC for RECOVSTATUS.

BDAM files

You can specify CICS support for backward recovery for BDAM files using the LOG parameter on the DFHFCT TYPE=FILE macro. You can also specify that you want automatic journaling of the various types of file access, using the JREQ and JID parameters of the FCT macro.

LOG=YES
If you specify LOG=YES, CICS provides backout recovery for the file. Using the services of the CICS recovery manager and log manager, CICS file control writes before-images of updated records to the system log stream.
JREQ=request-type(s) and JID=nn
Specify the file requests that you want CICS to journal automatically to the log stream mapped by the journal identifier specified on the JID parameter.

Although CICS does not provide forward recovery support for BDAM files, you can use the autojournal records to provide your own facility. JREQ=(WU,WN) is the equivalent of the CSD file definition parameters JNLUPDATE(YES) combined with JNLADD(BEFORE), providing the necessary images for forward recovery to a journal specified by JID=nn.

For information about defining BDAM file resource definitions, see the CICS Resource Definition Guide.

The CSD data set

The CICS system definition (CSD) VSAM data set is unique in that it is a CICS system data set that is managed by CICS file control. For this reason the CSD can’t be defined in the CSD, and is defined instead by system initialization parameters.

The recovery options equivalent to RECOVERY, FWDRECOVLOG, and BACKUPTYPE are CSDRECOV, CSDFRLOG, and CSDBKUP respectively. See the CICS System Definition Guide for information about defining the CSD.

File recovery attribute consistency checking (non-RLS)

For data sets accessed in non-RLS mode, ensure you have consistent recovery attributes between files that refer to the same base data set cluster or its paths.

The first file open for the base data set determines the base data set recovery attributes, and these are stored in the base cluster block (BCB). If, on a subsequent file open request, CICS detects an inconsistency between the file definition recovery attributes and those stored in the BCB, the open request fails.

See topic Inquiring on recovery attributes for information about finding the recovery attributes for files and data sets.

Overriding open failures at the XFCNREC global user exit

CICS provides a global user exit point, XFCNREC, to enable you to continue processing regardless of any inconsistencies in the backout setting for files associated with the same data set. If you use XFCNREC to suppress open failures that are a result of inconsistencies in the backout settings, CICS issues a message to warn you that the integrity of the data set can no longer be guaranteed.

Any CEMT, or EXEC CICS, INQUIRE DSNAME RECOVSTATUS command from this point onward will return NOTRECOVABLE, regardless of the recovery attribute that CICS has previously enforced on the base cluster. This condition remains until you remove the data set base control block (with a CEMT, or EXEC CICS, SET DSNAME REMOVE command), or perform a cold start.

The order in which files are opened for the same base data set determines the content of the message received on suppression of an open failure using XFCNREC. If the base cluster block is set as unrecoverable and a mismatch has been allowed, access to the data set could be allowed through an unrecoverable file before the data set is fully recovered.

See the CICS Customization Guide for programming information about XFCNREC.

CICS responses to file open requests

CICS file control uses the backout setting from the file definition to decide whether to log before-images for a file request.

CICS takes the actions shown in the following list when opening a file for update processing in non-RLS mode--that is, the file definition specifies RLSACCESS(NO), and the operations parameters specify ADD(YES), DELETE(YES) or UPDATE(YES) (or the equivalent SERVREQ parameters in the FCT entry.) If you set only READ(YES) and/or BROWSE(YES) CICS does not make these consistency checks. These checks are not made at resource definition or install time.

Any failure to open a file against a data set results in a message to the console. If necessary, the recovery options must be changed. To change the recovery attributes (held in the base cluster block) of a VSAM data set, you can use the CEMT, or EXEC CICS, SET DSNAME REMOVE command. This deletes the base cluster block, so CICS has no record of prior recovery settings for the VSAM data set. The next file to open against this data set causes a new base cluster block to be built and, if the file is opened for update, the data set takes on the recovery attributes of this file.

The base cluster block, together with its recovery attributes, and the inconsistency condition that may be set if you are using XFCNREC, are preserved even when all the files relating to the block are closed, and across warm and emergency restarts.

Implementing forward recovery with user-written utilities

If you use your own forward recovery programs, you must ensure they use the after images from the forward recovery log streams. The use of autojournal records written to a general log stream is not recommended for VSAM forward recovery.

For details of procedures for performing forward recovery, see Forward recovery procedures.

For programming information about the format of log and journal records, see the CICS Customization Guide.

Implementing forward recovery with CICS VSAM Recovery MVS/ESA

You can use CICS VSAM Recovery MVS/ESA (CICSVR) to recover lost or damaged VSAM data sets. For details, see Forward recovery with CICSVR.

[[ Contents Previous Page | Next Page Index ]]