Ron, Was EOS intended for disks that are removed to make sure they contain no valuable data or was it intended to prevent deleted data from being read again by another application? I thought the latter. Disks are usually removed because they break down, with valuable, undeleted data on them.
Does you proposal cover dumping a disk with DFdss/FDR and searching the tape for interesting data? Kees. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Ron Hawkins > Sent: 11 September, 2019 3:54 > To: [email protected] > Subject: Re: Erase On Scratch > > 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=1340 > 47 > > 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 ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
