AUTOERASE and AUTOEDSN Top Secret Control Options
Article ID: 17907
Updated On:
Products
Issue/Introduction
When using AUTOERASE, is there any performance impact when deleting a dataset?
Does Top Secret erase the dataset? What is the algorithm used? How does it work?
How can we prove datasets are, in fact, erased?
Resolution
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 Top Secret to erase the data, the answer is there isn't any I/O by Top Secret because 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, today, due to new hardware, it should take less time. It's also why it is recommended 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 is one way to prove it works:
First set:
TSS MODI AUTOERASE(YES) and TSS MODI AUTOEDSN(ADD,'Your.dsn')
Then:
- Allocate a sequential dataset LRECL 80 BLKSIZE 3200.
- Edit it and update it with anything, a string that you'll easily remember.
- Go to SYSVIEW.
- 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. - In batch or TSO ISPF, delete the dataset.
- 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. - 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
Opt NOOLDDATA PROMPT CONFIRM VERIFY WIDE READWRITE NOSCHLIM
Dsn FREE-SPACE-EXTENT Vol VOL001 Disp
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.
Feedback
