If the data set is an SMS data set, it is deleted using SVC 29. The update of the catalog entry is handled by the operating system.

If the data set is not an SMS data set and either it is not cataloged or the user indicates on panel ISRUADC2 (panel ISRUADC2 is shown if the volume is supplied) that it is not to be uncataloged, it is deleted using SVC 29.

If the data set is not an SMS data set and it is cataloged and/or the user indicates on panel ISRUADC2 (panel ISRUADC2 is shown if the volume is supplied) that it is to be uncataloged, this process is followed:

1. The data set is deleted using SVC 29 (SCRATCH).
2. The data set is uncataloged using SVC 26.

This order of processing is intended to minimize the possibility that an uncataloged data set will result if an error is encountered during the delete process. Some combinations of RACF® generic and discrete data set profiles and user access to the groups under which those profiles fall can cause this process to fail. If an error is encountered in this process the user is notified via a message of the status of the data set and catalog entries.

See the z/OS Security Server RACF Security Administrator's Guide or equivalent documentation for your security package, to determine the authorization levels required for each of these operations. The user will need authorization first to delete the data set and then to uncatalog the data set name. This will require adequate authorization to any discrete or generic data set profiles involved and to the catalogs involved. Be aware that a discrete data set profile is deleted when the data set is deleted.