How Do The CA Top Secret Control Options AUTOERASE and AUTOEDSN Work?

Document ID : KB000017907
Last Modified Date : 14/02/2018
Show Technical Document Details


When using AUTOERASE, is there any performance impact when deleting a dataset?
Does CA Top Secret erase the dataset? What is the algorithm used? How does it work?
How can we prove datasets are, in fact, erased?


Let's first see how it works:

The operating system data facility programs issue a RACROUTE with CLASS='DATASET', ENTITY specifying the name of a data set, and the parameter STATUS=ERASE. The security product (for the purposes of this discussion, it doesn't matter which product is in use) will set return codes and reason codes indicating whether or not the data set should be erased. (Reason code 0 means it does not need to be erased, reason code 4 means it should be erased).

The security product does not take any action which would cause the data to be erased other than setting this reason code.

Based on the response to this RACROUTE, the data facility programs will issue calls to erase the data. It doesn't matter what security product is in use. This code is identical for all products. And the security product does not actually erase the data. It simply makes a recommendation as to whether or not the data should be erased.

So, for the question of what I/O operations are performed by CA Top Secret to erase the data, the answer is there isn't any I/O by CA Top Secret because CA Top Secret does not erase the data. RACF does not erase the data. The security product is not responsible for erasing the data. The security product is only responsible for deciding whether or not the data is supposed to be erased. If you need to know exactly how the data is erased, this question should be directed to IBM (probably dfSMS support, which is responsible for data facility programs.

That being said, there is no way to exclude datasets if the AUTOERASE control option is set to ALL, ie AUTOERASE(ALL). But, you can set it to YES and declare a list of sensitive dataset(s) to be erased when deleted in the AUTOEDSN control option. Also, it takes longer to delete a dataset when erasing it.

Performance view:

The only note we have is from decades ago:

"It takes approximately one second per 1CYL to write X'00' data when setting AUTOERASE(ALL | YES)."

But, we can assume that today, due to the new hardware, it should take less time. It's also why we would recommend to use AUTOERASE in conjunction with AUTOEDSN for the most sensitive datasets.

How long it takes depends on the feature and technique use by dfSMS and is a question for IBM.

Here it is one way to prove it works:

First set:



  1. Allocate a sequential dataset LRECL 80 BLKSIZE 3200

  2. Edit it and update it with anything, a string that you'll easily remember.

  3. Go to SYSVIEW

  4. Enter "ZAP Your.dsn " (the one you allocated). SYSVIEW will display data as it follows:
    Dsn YOUR.DATASET                                             Vol VOL001 Disp FDA 00B6000001 TTR 000001 KL 00 DL 0050 XT 00B60000-00B6000E 1/1       Stat --------------------------------------------------------------------------- Offset    +0       +4       +8       +C         Data Record                 00000000  859981A2 85F0F0F1 40404040 40404040  *erase001        *           00000010  40404040 40404040 40404040 40404040  *                *           00000020  40404040 40404040 40404040 40404040  *                *           00000030  40404040 40404040 40404040 40404040  *                *           00000040  40404040 40404040 F0F0F0F0 F0F1F0F0  *        00000100* 

    Please, note the Volume id and the FDA.

  5. In batch or TSO ISPF, delete the dataset.

  6. Go back to SYSVIEW, enter "ZAP Your.dsn" (it should display what follows).

    ZAP$008E Dsname Your.DATASET not cataloged --------------------- Lvl 2 Row

    This confirms the dataset has been deleted and it is no longer accessible through catalog management.

  7. Enter "ZAP VOLUME Yourvolume" and then "CCHHR YourFDA", they should look like:

    ZAP VOLUME VOL001 followed by CCHHR 00B6000001. See below what is displayed.

    ZAP$017E Record not found ------------------------------------- Lvl 2 Row
    FDA 00B6000001 TTR 0AAA01 KL DL XT 00000000-2720000E 1/1 Stat
    Offset +0 +4 +8 +C No Record

This confirms no records are found because the DASD area where the dataset resided has been erased with x'00'. If not, you would see the data as shown in point 4.

See the CA Top Secret Control Options Guide for more details about the AUTOERASE() and AUTOEDSN() options.