Filter
Top Products
About this task
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 INQUIRE DSNAME RECOVSTATUS command that is issued 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 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.
v If a file definition refers to an alternate index (AIX) path and RECOVERY is ALL
or BACKOUTONLY, the AIX must be in the upgrade set for the base. This
means that any changes made to the base data set are also reflected in the AIX.
If the AIX is not in the upgrade set, the attempt to open the ACB for this AIX
path fails.
v If a file is the first to be opened against a base cluster after the last cold start, the
recovery options of the file definition are copied into the base cluster block.
v If a file is not the first to be opened for update against a base cluster after the
last cold start, the recovery options in the file definition are checked against
those copied into the base cluster block by the first open. There are the following
possibilities:
– Base cluster has RECOVERY(NONE):
- File is defined with RECOVERY(NONE): the open proceeds.
- File is defined with RECOVERY(BACKOUTONLY): the attempt to open the
file fails, unless overridden by an XFCNREC global user exit program,
which can allow inconsistencies in backout settings for files that are
associated with the same base data set.
- File is defined with RECOVERY(ALL): the open fails.
– Base cluster has RECOVERY(BACKOUTONLY):
- File is defined with RECOVERY(NONE): the attempt to open the file fails
unless overridden by an XFCNREC global user exit program to allow
inconsistencies in backout settings for files associated with the same base
data set.
- File is defined with RECOVERY(BACKOUTONLY): the open proceeds.
130 CICS TS for z/OS 4.1: Recovery and Restart Guide