Jesse, Nowadays you would still be long gone, but depending on media, pool occupancy, and page migration, there will likely be large areas of in the clear content, unless accessed by CKD.
Next time, ask your vendor about disk scrubbing. 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 <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Jesse 1 Robinson Sent: Thursday, 12 September 2019 03:08 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Erase On Scratch My only experience with EOS was as the *last* step of a DR test conducted (across country) at IBM Business Recovery Center in Tampa. Per IBM recommendation, we reinitialized all customer DASD volumes with full-volume data sets marked as EOS. Then we started a mass delete procedure and left for home. This was in the days of SLED. We were long gone when the procedure ended. -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Vernooij, Kees (ITOP NM) - KLM Sent: Tuesday, September 10, 2019 11:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Erase On Scratch 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:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Ron Hawkins > Sent: 11 September, 2019 3:54 > To: IBM-MAIN@LISTSERV.UA.EDU > 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 <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Larre Shiller > Sent: Wednesday, 11 September 2019 04:11 > To: IBM-MAIN@LISTSERV.UA.EDU > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
