To physically erase security-sensitive data at the time the data set extents are scratched, RACF® and DFSMS provide an erase-on-scratch facility. Erase-on-scratch ensures that when the data set is scratched (deleted or released for reuse), it cannot be read by any program running under control of an IBM® operating system. It enables you to protect both single and multivolume DASD data sets.

With the erase-on-scratch facility, you can designate that specific data sets with a particular security level or that all data sets should be physically erased when the data set is deleted or when some of the space that was allocated to the data set is released. During this process, RACF tells DFSMS that data erasure is required.

Erase-on-scratch might place an additional load on DASDs, which can have an impact on system performance, depending on how much erasure is being performed and how the erasure is being done. However, you can minimize the impact by various means.

• You have the option of controlling which data sets are erased. You can do this when you:
  • Create or modify a data set profile
  • Delete data sets using the RACROUTE REQUEST=AUTH postprocessing exit routines.
  Note:

  1. If you activate ERASE ALL, an installation exit cannot override the option to prevent data sets from being erased.
  2. Failsoft processing used with erase-on-scratch can affect the erase-on-scratch procedure and overall system performance. If a RACROUTE REQUEST=AUTH with STATUS=ERASE is processed when RACF is inactive during failsoft processing, and if the preprocessing exit grants authorization checking, the reason code specified in the exit parameter list is passed to the caller of the RACROUTE request. If the reason code equals 0, no erasure is performed. If the exit does not grant authority but failsoft processing does, the reason code from the exit equals 4 and indicates erasure is to be performed.
• Using data erasure with virtual array devices means that the storage subsystem erases data automatically without performance penalty. DFSMS checks the erase results from the RVA device. If the data was to be erased, DFSMS checks whether it was erased by the device. If it was not, DFSMS erases the data using other methods.

  Two general rules flow from this implementation:

  1. If you are using the DDSR function of IBM's extended data facility product (IXFP), specifying erase-on-scratch has minimal impact because DDSR performs the erasure in the overwhelming majority of cases.
  2. If you have data for which you want to enable erase-on-scratch, allocate the data on DDSR-enabled volumes.

By following these two rules, your data can be erased by the storage subsystem in the overwhelming majority of cases. In those rare cases where the storage subsystem was not able to erase the data, DFSMS erases the data using the ERASE CCW. This is also faster than on older devices because it does not need to wait for disk rotation.

For more information, see z/OS DFSMS Using Data Sets.