Larre, EOS operates on the basis that you overwrite the only location where the data has existed on the backend media in your storage. That's was an outdated concept back in the Iceberg/RVA days, and has become even more so with in-system and remote replication, load balancing and migration with thin provisioning, and write levelling in flash storage.
The reality of EOS is it is a dead concept for data at rest, and vendors are providing encryption and erasure processing to scrub media before removing it. I see the only goal of EOS as making the contents of the data set unavailable to z/OS, which does not require overwriting all the contents of the data set. With that in mind, I suggest that an option for EOS that nerfs HAR0 to an empty track, and leave it that. I believe all three vendors now keep HAR0 in a table with good locality of reference, so from the storage perspective this would be very efficient. It also eliminates the often huge amount of data transfer required to overwrite the old data, for the same resulting security from the host, which in turns reduces the latency of EOS when you delete a dataset. In all cases the data transfer reduction would flow on to replication. Move out of the past, and stop fooling ourselves that EOS is erasing anything, and optimise it to obfuscate the data from CKD host only, as that is all it is doing anyway. RON HAWKINS Director, Ipsicsopt Pty Ltd (ACN: 627 705 971) m+61 400029610| t: +1 4085625415 | f: +1 4087912585 -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Larre Shiller Sent: Wednesday, 11 September 2019 04:11 To: [email protected] Subject: [IBM-MAIN] Erase On Scratch Starting with z/OS 2.1 and continuing with z/OS 2.2, IBM has improved the performance of the Erase-On-Scratch (EOS) function over the pre-z/OS 2.1 releases by increasing the number of tracks that can be "erased" in each channel program from 1 to 255 to 12,240. The good news is that with those changes (on the software side) there was a drastic reduction in both elapsed time as well as an I/O count reduction, but these I/O operations are asynchronous and as such, most customers are concerned about suffering the performance hit that it takes to implement EOS, especially with replicated DASD. IBM believes that there is a lot of latent interest in using this function, but most customers are simply not using it because of the potential performance impact, including myself. And even if customers are using it, they are using it only for a subset of data sets. IBM would like to drive the use Erase-On-Scratch use up and get most, if not all customers using it because of the security exposure that exists and that IBM would like to eliminate. IBM has been having some internal discussions about improvements that revolve around a combination of hardware/microcode and z/OS software changes that, if implemented in z/OS and the DASD subsystem, would bring the overhead of using EOS down to the point where the overhead would not be noticed. But... the folks involved in bringing that to market need our help. There's an RFE that we can vote for that would show the level of interest in this function. If your Auditors or internal security folks are concerned about residual data on DASD and would like to see you using EOS but you are concerned about the overhead, please consider voting for the following enhancement to help bring this new functionality to market: https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=134047 Thanks! Larre Shiller US Social Security Administration ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
