IBM SC34-7012-01 manual CICS responses to file open requests, About this task

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.

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

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

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

130CICS TS for z/OS 4.1: Recovery and Restart Guide