DELETECATALOGENTRY


>>-+--------------------+--------------------------------------><
   +-DELETECATALOGENTRY-+   
   '-DELCATE------------'

DELETECATALOGENTRY specifies that the user wants to perform a disaster recovery and that the existing catalog entries for the target data sets might no longer be valid. If a target data set is cataloged but not available, then DFSMSdss performs a DELETE NOSCRATCH operation for the data set.

Specifying the DELETECATALOGENTRY command requires proper RACF® facility class authorization.

For more information about RACF, see z/OS DFSMSdss Storage Administration. For more information about protecting keywords with RACF, see z/OS Security Server RACF Security Administrator's Guide.

Caution: Use extreme care with the DELETECATALOGENTRY keyword. If any of the following conditions exist, a DELETE NOSCRATCH operation is performed:

Condition 1

The target data set is cataloged but it is not found on the volume indicated by the catalog.

Condition 2

The target data set is cataloged but the volume indicated by the catalog does not exist on the restoring system and the restoring system is not sharing catalogs with another system.

Condition 3

The target data set is cataloged but the volume indicated by the catalog is offline on the restoring system and the restoring system is not sharing catalogs with another system.

Condition 4

The target data set is cataloged but the volume indicated by the catalog does not exist on the restoring system and the restoring system is sharing catalogs with another system.

Condition 5

The target data set is cataloged but the volume indicated by the catalog is offline on the restoring system and the restoring system is sharing catalogs with another system.

Condition 6

The target data set is a multivolume data set and some, but not all of the data, is no longer available. For this purpose, a multivolume data set is one in which any part of the data set resides on more than one volume. Examples include the following:

A VSAM KSDS with the data- and index-components on one volume and an alternate index (AIX®) on another volume.
A VSAM KSDS with the index-component on a different volume than the data-component.
A key-range VSAM data set with the key-ranges residing on more than one volume.

For conditions 1 and 2, it is appropriate to use DELETECATALOGENTRY to have DFSMSdss perform a DELETE NOSCRATCH operation for the catalog entries.

Condition 1 typically occurs during a disaster recovery when DFSMSdss restores or imports the catalogs before recovering the data sets. The target data set does not exist on the volumes indicated by the catalog. The restore will not be successful unless you or DFSMSdss delete the data set entries in the catalogs.

Condition 2 typically occurs during a disaster recovery when DFSMSdss restores the data sets to different volumes on a different operating system. DFSMSdss catalogs the target data sets, but points to volumes that do not exist on the target system. The restore will not be successful unless you or DFSMSdss delete the data set entries in the catalogs.

If you specify DELETECATALOGENTRY for conditions 3 through 6, the following damage is most likely to occur:

Condition 3 typically occurs during a disaster recovery when DFSMSdss restores the data sets to different volumes on a different operating system. DFSMSdss cataloged the target data sets, but points to offline volumes on the target system. The restore will not be successful unless you or DFSMSdss delete the data set entries in the catalogs.
Condition 3 can also occur in any environment where volumes are varied on and offline.
If you specify DELETECATALOGENTRY and then vary the volume back online, you might find that there aretwo copies of a data set: the original data set on the volume that was varied offline and the restored data set. DFSMSdss will no longer catalog the original data set.
Conditions 4 and 5 typically occur in a shared system environment with a nonsymmetric system configuration. The following examples apply:
- There are shared catalogs between two systems.
- A data set is dumped from system A, but restored into system B.
- The data set is cataloged in system A in a catalog that is shared by system B.
- The volume containing the data set and, if applicable, its VVDS is on system A and is unavailable to system B.
  Restriction: If you specify DELETECATALOGENTRY and then vary the volume back online, you might find that there are two copies of a data set: the original data set on the volume that was varied offline and the restored data set. If this happens, DFSMSdss can no longer catalog the original data set.
DFSMSdss attempts to detect Condition 6 and issues an error message instead of performing the DELETE NOSCRATCH. However, it will not always be possible to do so. In that event, the DELETE NOSCRATCH is performed and DFSMSdss attempts to restore the data set with one of the following results:
- DFSMSdss successfully restores the data set, and there is no residual data from the original data set. In this case, there is nothing further for you to do.
- DFSMSdss successfully restores the data set, but there is residual data from the original data set. Although DFSMSdss restored the data set, you might find, for example, that there is an uncataloged AIX from the original data set. In this case, you will have to perform other corrective actions. These are the same actions that you would have had to perform even if you had not used the DELETECATALOGENTRY keyword.
- An error occurs during the restore that prevents the data set from being restored. The error results from the fact that the data set was only partially missing. For example, residual data and the VSAM Volume Record (VVR) might exist on a second volume. When the data set that is being restored is extended to that volume, a duplicate entry condition is created. Again, if this occurs, you will have to perform other corrective actions before you can successfully restore the data set.

Note:

Use DELETECATALOGENTRY only for logical data set restore.
Do not use DELETECATALOGENTRY to restore partially damaged volumes or data sets.
You cannot use DELETECATALOGENTRY to delete catalog entries for any of the following:
- User catalogs.
- Migrated data sets (VOLSER=MIGRAT).
- The SYSRES volume (VOLSER=******).
- A data set for which the volser(s) in the catalog do not match either the source volser(s) from the dump tape or the target volser(s) specified with OUTDD/OUTDYNAM.
If you are performing a disaster recovery and the original volumes are not available on the restoring system, you should also specify the IMPORT parameter. If you do not specify the IMPORT keyword, the system might prompt you to mount the volumes on which the target data resides (as indicated by the catalog). Even if you reply ‘CANCEL’, DFSMSdss attempts to perform a DELETE NOSCRATCH on the data set because it does not recognize the ‘CANCEL’ request. Even if the DELETE NOSCRATCH is successful, DFSMSdss might cause the following results:
- DFSMSdss might fail to allocate the volume
- DFSMSdss might issue the message ADR405E
- DFSMSdss might not restore the data set
DELETECATALOGENTRY will not delete any catalog entry when the phantom entry indicates a different type of data set than the source data set.