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.
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:
TSS MODI AUTOERASE(YES) and TSS MODI AUTOEDSN(ADD,'Your.dsn')
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*
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.
Release: TOPSEC00200-15-Top Secret-Security