The information in the remainder of this section might be required by the system administrator to recover from error situations due to incorrect operating procedures or hardware failures.
The main data fields used by the BWO facility are:
C = century (0=1900, 1=2000, etc.)
YY = year
DDD = day
HH = hours
MM = minutes
SS = seconds
T = tenths of a second
F = + sign
The DFSMSdfp field dictionary name is VVRRDATA.The attribute flags and recovery point are managed by VSAM in the primary data VSAM volume record (VVR) of the base cluster, which is in the VSAM volume data set (VVDS). There is only one primary base cluster VVR for each VSAM sphere, which is why BWO eligibility is defined at the sphere level. For more information, see DFSMS/MVS Managing Catalogs.
BWO processing affects the following operations in a CICS system:
Each of these operations is discussed in the following sections.
Different processing is done for each of the following three cases when a file is opened for update:
Each case is described later in this section.
In all three cases, CICS issues warning message DFHFC5812 if BACKUPTYPE(DYNAMIC) is specified for a VSAM AIX data set that is being opened as a standalone base cluster data set. The AIX data set must default to the BACKUPTYPE already defined for the sphere.
Also, if the file-open operation fails during BWO processing, the ACB will be open. So CICS closes the ACB before indicating the file-open operation has failed. This affects CICS statistics.
If the file is opened for read-only, and the data set ICF catalog indicates that the data set is back-level, the file-open operation fails.
In all cases, a file-open operation fails with error messages if the ICF catalog indicates that the data set is back-level. A back-level data set is one that:
The following processing is done for the first file that is opened for update against a VSAM base cluster data set after a CICS cold start. (In this case, the update use count in the DSNB for the base cluster is always zero.)
CICS calls the DFSMSdfp IGWABWO callable service to inquire on the BWO attributes in the ICF catalog.
However, if the ICF catalog indicates that the data set is already eligible for BWO, IGWABWO just sets the recovery point to the current time. CICS issues a message, and you can discard any BWO backups already taken in a previous batch window.
However, if the ICF catalog indicates that the data set is currently eligible for BWO, IGWABWO makes it ineligible for BWO and sets the recovery point to the current time. CICS issues a message, and you can discard any BWO backups already taken in a previous batch window.
If BWO support is requested and the appropriate level of DFSMSdfp (as described in What is needed to use BWO) is not correctly installed on the processor where CICS is running, the first file-open operation fails with error message DFHFC5811. Subsequent file-open operations are allowed, but CICS issues aa attention message.
CICS also issues an attention message (DFHFC5813) for the first file-open operation if the appropriate levels of DFSMShsm and DFSMSdss are not installed on the processor where CICS is running. Ensure that they are installed on the processor where the BWO backup is to be made.
The following processing is done when a subsequent file is opened for update against a VSAM base cluster data set and the update use count in the DSNB for the base cluster is not zero.
The ICF catalog has already been validated and set by the first file-open operation, so CICS just checks the BACKUPTYPE attributes in the FCT and the DSNB. If they are not consistent, the file-open operation fails with error messages. You must then either correct the CEDA definition, or REMOVE the DSNB after closing all files that are open against the base cluster data set.
The following processing is done when a subsequent file is opened for update against a VSAM base cluster data set and the update use count in the DSNB for the base cluster is zero. This situation could exist in the following cases:
CICS checks the BACKUPTYPE attributes in the FCT and the DSNB. If they are inconsistent, the file-open operation fails with error messages. Either correct the CEDA definition, or REMOVE the DSNB after closing all files that are open against the base cluster data set. If the BACKUPTYPE attributes are consistent, CICS uses the DFSMSdfp IGWABWO callable service to inquire on the BWO attributes in the ICF catalog.
However, if the ICF catalog indicates that the data set is already eligible for BWO, IGWABWO resets the recovery point to the current time. CICS issues an attention message; you can discard any BWO backup copies already taken in a previous batch window.
However, if the ICF catalog indicates that the data set is currently eligible for BWO, IGWABWO makes it ineligible for BWO and sets the recovery point to the current time. CICS issues an attention message; you should discard any BWO backup copies already taken in a previous batch window.
When the last file that is open for update is closed against a VSAM base cluster data set, CICS uses the DFSMSdfp IGWABWO callable service to update the ICF catalog to indicate that the data set is no longer eligible for BWO and to reset the recovery point to the current time.
If a VSAM split has occurred while a file was open, CICS calls IGWABWO at file-close time to update the ICF catalog to prevent further BWO backups. If DFSMShsm is currently taking a BWO backup, it will discard the backup at the end of the backup operation.
The BWO attributes indicating that a split has occurred and that the data set is eligible for BWO are restored when the next file is opened for update against the data set. This ensures that DFSMShsm takes the correct action if a split occurs during backup processing, which spans CICS updating a file (causing a VSAM split), the file being closed, and then the file being reopened.
When CICS is terminated by a normal shutdown, all CICS files are closed. The ICF catalog is updated to suppress BWO activity during the batch window between CICS sessions. After an uncontrolled or immediate shutdown, or if there is a failure during file closing, the data set remains open and the BWO flags are not reset. See Shutdown and restart.
In some circumstances, it might not be possible to take either BWO or non-BWO backups of a data set. The VSAM UPDATE ACB ENQs for a sphere might remain, even though there are no files open for update against this sphere. This could happen if a VSAM sphere contains an AIX in the upgrade set and the following actions occur:
The data set is now ineligible for BWO backups because CICS file control has reset the BWO attributes in the ICF catalog. But, until all open ACBs in the sphere are closed, VSAM will not close the internal ACBs that are open for update, and thus it is not possible to take non-BWO backups either.
To remedy this situation, either:
The way CICS closes files is determined by whether the shutdown is controlled, immediate, or uncontrolled.
During a controlled shutdown, CICS closes all open files defined in the FCT. This ensures that, for files that are open for update and eligible for BWO, the BWO attributes in the ICF catalog are set to a ‘BWO disabled’ state
If a failure occurs during shutdown so that CICS is unable to close a file, CICS issues warning message DFHFC5804. In this case, check the BWO attributes and, if necessary, either use DFSMSdfp IGWABWO callable service to set the attributes, or discard any BWO backups that are taken in the batch window that follows the shutdown.
During an immediate or uncontrolled shutdown, CICS does not close the files defined in the FCT, and so the BWO attributes in the ICF catalog are not updated.
Use the DFSMSdfp IGWABWO callable service to set the attributes (see An assembler program that calls DFSMS callable services for an example of how to do this). Do not run any batch jobs before the next CICS restart. If you do, for releases prior to DFSMS 1.2, discard any BWO backups that are taken in the batch window.
For DFSMS 1.2 onward, the controls in DFSMS allow DFSMSdss to detect a backup that is invalidated if CICS applications are shut down (normally or abnormally) and if batch programs are executed that update the data set while the BWO backup is in progress. This allows DFSMSdss to discard the backup, which prevents DFSMShsm from erroneously discarding the oldest valid backup from the inventory maintained by DFSMShsm.
At the next CICS restart, the following BWO-dependent actions can occur when a data set is opened for update:
BWO backups are taken at the VSAM sphere level. You can use DFSMShsm or DFSMSdss to take the backup copy. You are recommended to use DFSMShsm because, without DFSMShsm installed, you must supply automatic class selection (ACS) routines to fulfil the SMS requirements for BWO support.
When you use DFSMShsm, you still use DFSMSdss as the data mover. You can specify this using the DFSMShsm SETSYS command:
SETSYS DATAMOVER(DSS)
The DFSMS processing at the start of backup is dependent on the DFSMS release level. For releases prior to DFSMS 1.2, DFSMSdss first checks the BWO attributes in the ICF catalog to see if the data set is eligible for BWO. If it is, the backup is made without attempting to obtain exclusive control and serialize updates to this data set.
For DFSMS 1.2 onward, DFSMSdss first tries to obtain exclusive control of the data set. If DFSMSdss succeeds, an enqueued form of backup takes place. If this serialization fails, DFSMSdss checks the BWO attributes in the ICF catalog to see if the data set is eligible for BWO. If it is, a BWO backup is attempted. If it is not eligible, the backup attempt fails.
This change will prevent DFSMS starting a BWO backup after CICS has abnormally terminated.
At the end of the BWO backup, DFDSS again checks the BWO attributes. If the data set is no longer eligible for BWO, the backup is discarded. Events that cause this situation are:
At the start of a backup, if the state is ‘BWO enabled and VSAM split occurred’, DFSMSdss resets the state to ‘BWO enabled’. Then, if another VSAM split occurs, the backup will be discarded at the end of the backup operation.
DFSMS access method services import and export operations do not support BWO in releases earlier than DFSMS 1.2. Access method services always serializes the data set before exporting it; and when the IMPORT function is used, the BWO attributes in the ICF catalog are not updated.
For DFSMS 1.2 onward, access method services supports the import and export of BWO attributes.
CICS, DFSMSdfp, DFSMSdss, and an SMSVSAM server can all update the BWO attributes in the ICF catalog. To prevent errors, DFSMSdss fails a BWO backup if one of the following state changes is attempted during the backup:
DFSMSdfp must now disallow the pending change to ‘BWO enabled’ (and DFSMSdss must fail the backup) because, if the split did not finish before the end of the backup, the invalid backup would not be discarded.
DFSMSdfp must now disallow the pending change to ‘BWO enabled’ (and DFSMSdss must fail the backup) to prevent the possibility of a BWO backup being taken during a subsequent batch window.
When a BWO backup copy of a data set is restored, using DFSMShsm RECOVER or DFSMSdss RESTORE, the data set must be serialized to prevent any updates during the restore operation. When the restore is complete, the BWO attributes in the ICF catalog are changed to a ‘Backup restored by DFSMShsm’ state. CICS cannot open the data set until forward recovery has been completed successfully.
DFSMSdss also resets the recovery point in the ICF catalog to the value it contained when the backup was made. This ensures that forward recovery starts at the correct point. This value should not be used for forward recovery of a non-BWO backup.
If a BWO backup is restored in storage that is not SMS-managed, the BWO attributes in the ICF catalog are lost. Thus forward recovery is not possible.
The forward recovery utility uses the forward recovery logs to recover a base cluster. To do this, it must know:
Each data set after-image record on the log is associated with a file name. However, there might be many files associated with the same data set; therefore, when a file is opened, the association between the file and the data set is recorded on the forward recovery log by a tie-up record. This information is also written to the log of logs. For non-BWO backups, the forward recovery utility uses this tie-up record to apply the log records to the correct data sets.
When a BWO is taken for a data set opened in RLS mode, DFSMSdss notifies each CICS region having an open ACB for the data set. On receipt of this notification, each CICS allows all units of work with updates for the data set to complete, and then they write the tie-up records to the forward recovery log and the log of logs, and replies to DFSMSdss.
For BWO backups, it is usually not necessary for the forward recovery utility to process a log from file-open time. Therefore, the tie-up records for all open files are written regularly on the log during activity-keypoint processing, and the time that they are written is recorded. To reduce the number of tie-up records if the activity keypoint frequency is high (such as for some large systems), CICS ensures that there is at least 30 minutes’ separation between sets of tie-ups on the log.
The recovery point is a time that can be converted to a position on a forward recovery log. Recovery of the data set requires only the records that are written after that position. Thus all previous records can be ignored by the forward recovery utility.
The recovery point is stored in the ICF catalog. It is initialized when the first file is opened for update against the data set, and updated during activity-keypoint processing and when the file is closed.
The recovery point is not the time of the current keypoint, as there might still be some uncommitted log records that have not been forced. Instead, it is the time of the start of the last keypoint that wrote a complete set of tie-up records and that completed earlier than the oldest uncommitted write to a forward recovery log.
CICSVR fully supports BWO and the log of logs. If you do not use CICSVR, ensure that your forward recovery utility is able to:
The forward recovery utility should ALLOCATE, with DISP=OLD, the data set that is to be recovered. This prevents other jobs accessing a back level data set and ensures that data managers such as CICS are not still using the data set.
Before the data set is opened, the forward recovery utility should set the BWO attribute flags to the ‘Forward recovery started but not ended’ state. This prevents DFSMShsm taking BWO backups while forward recovery is in progress. To prevent CICS opening a back level data set, the utility should perform this state change for all data sets in a system that supports BWO, even if some do not use BWO.
The forward recovery utility should use the BWO time stamp for the data set in the ICF catalog, set by DFSMSdss when the data set is restored, to determine the starting point in the forward recovery log to start the forward recovery.
If forward recovery completes successfully, the utility should set the BWO attributes to the ‘BWO disabled’ state before the data set is closed.
If forward recovery does not complete successfully, the utility should leave the BWO attributes in the ‘Forward recovery started but not ended’ state to ensure that CICS does not open a back-level data set.
If forward recovery does not complete successfully:
Alternatively, if you use a VSAM forward recovery utility that does not update the BWO attributes during forward recovery, you may use these commands to reset the backup-restored-by-DFSMShsm state prior to subsequent CICS file control access.
Before you can forward recover a data set that was restored from a copy made using BWO, ensure that no AIXs are in the upgrade set. CICSVR checks the upgrade set of data sets restored from BWO copies and issues a message if AIXs are found.
To forward recover such a data set, after the restore, use the AMS ALTER or DELETE command to remove or delete the AIXs from the upgrade set. After forward recovery has completed successfully, you can re-create the upgrade set by rebuilding the AIXs using the access method services BLDINDX command.