Re: Erase On Scratch

[Ron Hawkins]

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  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  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  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 

Re: Erase On Scratch

[Ron Hawkins]

Kees,

I believed the design of EOS is your latter case, but I feel there is some 
questionable belief out there that it can address the first case. Nerfing HAR0 
addresses your latter case.

Have you ever swapped out an old DASD controller for a new one? What did you do 
with the old drives? Drives replaced due to failure prediction can still be 
scrubbed, but may require connection to an external interface for single 
drives. There are a rare, few customers that have failed drives sitting on 
shelves, and sometimes they degauss these or have some fun with sledgehammers 
on the weekend (true story). You can have flash drives wiped as well, but it 
would be by a 3rd party. Flash write levelling defeats Controller or software 
secure-erase. Think log-structured files in Iceberg.

Yes, my proposal covers dumping the DASD with a CKD utility. A physical dump 
with DFSMSdss will honour HAR0 empty tracks, and will not read anything else. 
How would it know what to read with no data length information? More 
interestingly, if you could read an empty track, what would the controller 
return from a reclaimed or migrated empty track? For IBM and HDS, HAR0 is just 
a field in a table stored separately from the actual track contents.

Thanks for asking Kees, and making me exercise some brain cells. If I am wrong 
on anything, I hope someone will educate me.


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  On Behalf Of 
Vernooij, Kees (ITOP NM) - KLM
Sent: Wednesday, 11 September 2019 16:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] 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  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 thi

Re: Erase On Scratch

[Lisa Gundy]

Larre,
This has proven useful, as the number of votes for this RFE have gone up 
overnight.  This will help us in identifying priorities.  One thing we noticed 
was that this will require changes in microcode and software, but there is no 
open RFE on the DS8k side for this function.  Would you be willing to open a 
related customer requirement against DS8000?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Erase On Scratch

[Jesse 1 Robinson]

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  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  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 abo

Re: Erase On Scratch

[Vernooij, Kees (ITOP NM) - KLM]

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  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_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 ac

Re: Erase On Scratch

[Ron Hawkins]

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  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_ID=134047

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

Erase On Scratch

[Larre Shiller]

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_ID=134047

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

Re: Erase on Scratch

[Larre Shiller]

Ed -

Yes.

Larre

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Erase on Scratch

[Edward Gould]

Larre:

Are you currently running 2.2 on all your production machines?

Ed
> On Apr 24, 2017, at 4:57 AM, Larre Shiller 
> <0102cb4997b0-dmarc-requ...@listserv.ua.edu> wrote:
> 
> I have been involved in a number of offline discussions as well as multiple 
> IBM PMRs and problem records with our DASD hardware vendor concerning EOS and 
> although this is potentially a most useful function, the overhead involved is 
> not zero--there will always be *some* amount of overhead involved in 
> re-writing every bit of a data set, no matter how much improvement IBM has 
> made to the function at the OS level (such as the 95+% reduction in EXCP's 
> since the initial implementation of EOS).  During our testing, we find that 
> it takes an additional 1 hour of processing time for every 500G of data in 
> order to use EOS.  If you have a tight batch window or any kind of 
> time-sensitive processing, you should make sure that you can afford to use 
> EOS before simply activating it for every data set in your enterprise.  Since 
> this is a security-related function, I will not comment publicly 
> if/when/where we do or do not use it, but I will simply recommend that you 
> perform a benchmark evaluation of the overhead involved on your hardware 
> before activating EOS.
> 
> Larre Shiller
> US Social Security Administration
> 
> "The opinions expressed in this message are mine personally and do not 
> necessarily reflect the opinion of the US Social Security Administration 
> and/or the US Government."
> 
> --
> 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

Re: Erase on Scratch

[Larre Shiller]

I have been involved in a number of offline discussions as well as multiple IBM 
PMRs and problem records with our DASD hardware vendor concerning EOS and 
although this is potentially a most useful function, the overhead involved is 
not zero--there will always be *some* amount of overhead involved in re-writing 
every bit of a data set, no matter how much improvement IBM has made to the 
function at the OS level (such as the 95+% reduction in EXCP's since the 
initial implementation of EOS).  During our testing, we find that it takes an 
additional 1 hour of processing time for every 500G of data in order to use 
EOS.  If you have a tight batch window or any kind of time-sensitive 
processing, you should make sure that you can afford to use EOS before simply 
activating it for every data set in your enterprise.  Since this is a 
security-related function, I will not comment publicly if/when/where we do or 
do not use it, but I will simply recommend that you perform a benchmark 
evaluation of the overhead involved on your hardware before activating EOS.

Larre Shiller
US Social Security Administration

"The opinions expressed in this message are mine personally and do not 
necessarily reflect the opinion of the US Social Security Administration and/or 
the US Government."

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Erase on Scratch

[Cheryl Watson]

Hi all,

We did a survey at SHARE that you might find interesting.  Here are three 
references relating to Erase on Scratch.  Frank and I STRONGLY recommend 
exploiting it to improve security on the mainframe:

http://watsonwalker.com/cheryls-list-183/ - Blog post recommending EoS

http://watsonwalker.com/cheryls-list-188/ - Blog post describing enhancement to 
EoS

http://s3-us-west-1.amazonaws.com/watsonwalker/ww/wp-content/uploads/2016/01/28153156/PR150306.pdf
 - The Cheryl and Frank zRoadshow at SHARE, March 2015

Best regards,
Cheryl

=
Cheryl Watson
Watson & Walker, Inc.
www.watsonwalker.com


-Original Message-
Date:Fri, 21 Apr 2017 05:14:38 -0500
From:Bill Wilkie <billwil...@hotmail.com>
Subject: Erase on Scratch

I have been looking into the Erase on Scratch capability to erase all extents 
of a data set but much of my research indicates that:

1. You must set up the data set names individually.
2. It will not erase &Temp data set names unless you:
 a. Make the &TEMP name a permanent name.
 b. Map the temp name to a permanent name already being erased.
 c. SETROPS ERASE(ALL) to erase all deleted data sets, which is very slow.

My question is "Is anyone using it" and if so how is it working out?
If you are not using it Why not?

--
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

Re: Erase on Scratch

[Robert S. Hansel (RSH)]

Bill,

Here are the results of a survey I did on RACF ERASE a few years ago.

http://www.rshconsulting.com/surveys/RSH_Consulting__RACF_Survey_019__ERASE.pdf

Most installations don't use ERASE because they think there will be performance 
problems. There have been significant improvements in the performance of ERASE 
in z/OS 2.1 and 2.2.

Regards, Bob

Robert S. Hansel  *** Celebrating 30 years working with RACF ***
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

Upcoming RSH RACF Training - WebEx
- RACF Audit & Compliance Roadmap - MAY 15-19, 2017
- RACF Level I Administration - APR 25-28, 2017
- RACF Level II Administration - NOV 13-17, 2017
- RACF Level III Admin, Audit, & Compliance - OCT 2-6, 2017
- RACF - Securing z/OS UNIX  - OCT 23-27, 2017


-Original Message-
Date:Fri, 21 Apr 2017 05:14:38 -0500
From:Bill Wilkie <billwil...@hotmail.com>
Subject: Erase on Scratch

I have been looking into the Erase on Scratch capability to erase all extents 
of a data set but much of my research indicates that:

1. You must set up the data set names individually.
2. It will not erase &Temp data set names unless you:
 a. Make the &TEMP name a permanent name.
 b. Map the temp name to a permanent name already being erased.
 c. SETROPS ERASE(ALL) to erase all deleted data sets, which is very slow.

My question is "Is anyone using it" and if so how is it working out?
If you are not using it Why not?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Erase on Scratch

[Edward Gould]

> On Apr 21, 2017, at 9:35 PM, Jesse 1 Robinson  wrote:
> 
> In a prior life at a bank, we did a DR exercise at a vendor business recovery 
> site. At the end, we were supposed to erase all the data we had restored. We 
> did the RACF needful to erase on delete, started some kind of 'delete all' 
> process, and went out to lunch. Came back a few hours later. It was still 
> running. Those were the days of slow CPUs and slow DASD. We had a plane to 
> catch. Asked the vendor to let it run to completion. Took off.
> 
> If you can't trust IBM, who can you trust?
> 

Skip:

If I remember correctly there is a fast erase with ICKDSF. If I remember 
correctly it takes 2 minutes or less per volume.
I had a DASD IBMer tell me about it. We used it a fair amount with the amount 
of DASD we swapped in and out.
This was back in the real 3390 days.
Our management was really into making sure not any of our data got outside the 
glass room.
I didn’t want to tell them that the communication was the weak link, that 
manager was my bosses boss.
Edf

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Erase on Scratch

[Jesse 1 Robinson]

In a prior life at a bank, we did a DR exercise at a vendor business recovery 
site. At the end, we were supposed to erase all the data we had restored. We 
did the RACF needful to erase on delete, started some kind of 'delete all' 
process, and went out to lunch. Came back a few hours later. It was still 
running. Those were the days of slow CPUs and slow DASD. We had a plane to 
catch. Asked the vendor to let it run to completion. Took off.

If you can't trust IBM, who can you trust?

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Friday, April 21, 2017 5:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Erase on Scratch

On Fri, 21 Apr 2017 11:12:25 +, Vernooij, Kees (ITOPT1) - KLM 
<kees.verno...@klm.com> wrote:

>You don't mention what you want to use it for, but with SMS managed 
>datasets part of the problem was eliminated, because SMS managed 
>datasets automatically get an EOF. You can't anymore simply allocate a dataset 
>and start reading the old data on the tracks.

True. However, that only erases the data from the first track of the data set, 
and anyone using EXCP-level programming can still read the rest  of the data.

--
Walt


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Erase on Scratch

[Walt Farrell]

On Fri, 21 Apr 2017 11:12:25 +, Vernooij, Kees (ITOPT1) - KLM 
 wrote:

>You don't mention what you want to use it for, but with SMS managed datasets 
>part of the problem was eliminated, because SMS 
>managed datasets automatically get an EOF. You can't anymore simply allocate a 
>dataset and start reading the old data on the 
>tracks.

True. However, that only erases the data from the first track of the data set, 
and anyone using EXCP-level programming can still read the rest  of the data.

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Erase on Scratch

[Vernooij, Kees (ITOPT1) - KLM]

You don't mention what you want to use it for, but with SMS managed datasets 
part of the problem was eliminated, because SMS managed datasets automatically 
get an EOF. You can't anymore simply allocate a dataset and start reading the 
old data on the tracks.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bill Wilkie
> Sent: 21 April, 2017 12:15
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Erase on Scratch
> 
> I have been looking into the Erase on Scratch capability to erase all
> extents of a data set but much of my research indicates that:
> 
> 1. You must set up the data set names individually.
> 2. It will not erase &Temp data set names unless you:
>  a. Make the &TEMP name a permanent name.
>  b. Map the temp name to a permanent name already being erased.
>  c. SETROPS ERASE(ALL) to erase all deleted data sets, which is very
> slow.
> 
> My question is "Is anyone using it" and if so how is it working out?
> If you are not using it Why not?
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Erase on Scratch

[Bill Wilkie]

I have been looking into the Erase on Scratch capability to erase all extents 
of a data set but much of my research indicates that:

1. You must set up the data set names individually.
2. It will not erase &Temp data set names unless you:
 a. Make the &TEMP name a permanent name.
 b. Map the temp name to a permanent name already being erased.
 c. SETROPS ERASE(ALL) to erase all deleted data sets, which is very slow.

My question is "Is anyone using it" and if so how is it working out?
If you are not using it Why not?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN