Re: Other DASD Erase programs

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/28/2005
   at 12:12 PM, Walt Farrell <[EMAIL PROTECTED]> said:

>Writing an EOF is different.  That replaces just one block on the
>track,  leaving the rest of the data (in the subsequent blocks)
>intact. 

No, it erases the remainder of the track, at least as far as normal
CCW's are concerned.

>ZAP and other programs can read the rest of the data in that case, 

He's dead, Jim.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/27/2005
   at 09:19 PM, David Speake <[EMAIL PROTECTED]> said:

>Anykahow, will ZAP recover data as asked?

No.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Ron and Jenny Hawkins]

Gabe.

On the HDS 9900V a secure erase of a volume or LUN was introduced as a
stealth feature. 

It is coming, or may already have arrived on the USP. I'll check over the
weekend, or perhaps Raymond Noal will have a look if he is reading his
IBMMAIN mail tonight/today.

It won't help you erase you IBM and EMC DASD though :(

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Gabe Torres
> Sent: Wednesday, 29 June 2005 6:44 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Other DASD Erase programs
> 
> Hello List,
>  I have gleaned the Archives on this subject, and have found NEW ERA's
> FAST DASD ERASE, and  IBM's DFDSS, ICKDSF and IEBDG.
> 
> Is the List aware of any other Vendors or products that offer a solution
> ($$) to writing over DASD at a DR site?
> Our Budget and Accounting processes expect more than one Vendor Review.
> (..hhh Gov'mnt!)
> 
> TIA,
> Gabe Torres - Systems Programmer
> State of Nevada
> Dept of Information Technology - Computing Div.
>  This communication, including any attachments, may contain confidential
> information and is intended only for the individual or entity to whom it
> is addressed. Any review, dissemination or copying of this communication
> by anyone other than the intended recipient is strictly prohibited. If
> you are not the intended recipient, please contact the sender by reply
> e-Mail and delete all copies
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Bruce Black]

z/OS performs data erasure by telling the control unit to erase 
tracks.  That results in the track having only an R0 record, and the 
rest of the track is overwritten with binary zeros.  No program that 
uses normal CCW interfaces to the DASD can then read anything on the 
track.


Writing an EOF is different.  That replaces just one block on the 
track, leaving the rest of the data (in the subsequent blocks) 
intact.  ZAP and other programs can read the rest of the data in that 
case, but cannot read the original block that you overwrote.



Sorry, Walt, you are wrong. 

The effect of the ERASE commands varies by vendor.  Some vendors do 
overwrite the track with zeros or other values, some do not.  However, 
the logical effect is the same in all cases; the original data on the 
track cannot be accessed from the mainframe host (CKD commands). 

Writes come in 2 flavors.  UPDATE writes simply update the contents of 
an existing block.  But FORMAT writes are used to write new blocks, and 
must be use to change the length of existing blocks (actually by 
overwriting them).  So writing an EOF is a format write.   Format writes 
always erase the rest of the track, which will make all previous blocks 
unavailable.  Again, it varies by vendor as to whether the data is 
physically ovewritten, but the old records are NOT retrieveable by ZAP 
or any other program.


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Walt Farrell]

On 7/28/2005 6:52 AM, [EMAIL PROTECTED] wrote:
 
In a message dated 7/27/2005 9:19:58 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:
 


I was wondering if ZAP would/not allow one to
retrieve data from a  track that had been "cleared" by writing R0 or EOF at
beginning of the  track. I guess Radoslaw Skorupka's English comes out better
than mine.  Can I blame it on American television? Hmm, no, come to think of
it.  English is NOT spoken on 'American' television'.



?Anykahow, will ZAP  recover data as asked?



z/OS performs data erasure by telling the control unit to erase tracks. 
 That results in the track having only an R0 record, and the rest of 
the track is overwritten with binary zeros.  No program that uses normal 
CCW interfaces to the DASD can then read anything on the track.


Writing an EOF is different.  That replaces just one block on the track, 
leaving the rest of the data (in the subsequent blocks) intact.  ZAP and 
other programs can read the rest of the data in that case, but cannot 
read the original block that you overwrote.


Walt Farrell

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Bill Fairchild]

 
In a message dated 7/28/2005 6:55:04 A.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:

As I  understood David's American language , he meant security  
exposure, not data recovery possibility. In other words, ZAP can be used  
(or cannot be - that is the question)to disclose data, unformatted, in  
sysprint, etc.  So there is risk a of "quick erase".

Regarding  to the original question: I don't know whether ZAP can be used 
for that,  but I believe, it is protected by RACF DASDVOL/GDASDVOL class 
profiles. At  least VTOC is.





IMASPZAP can be used to display and/or alter any data which the system's  
security rules allow, including allocated data sets that belong to other  
users.  
If you want to alter data inside a VTOC, I believe that a WTOR is  sent to 
the master console.
 
Bill Fairchild

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[R.S.]

Bill Fairchild wrote:

 
In a message dated 7/27/2005 9:19:58 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:
 


I was wondering if ZAP would/not allow one to
retrieve data from a  track that had been "cleared" by writing R0 or EOF at
beginning of the  track. I guess Radoslaw Skorupka's English comes out better
than mine.  Can I blame it on American television? Hmm, no, come to think of
it.  English is NOT spoken on 'American' television'.



?Anykahow, will ZAP  recover data as asked?




IMASPZAP will not retrieve or recover data, if I understand what I think  you 
mean by those words.  ZAP will only read what is on the track and  format it 
for displaying to the SYSPRINT file, which is typically then read  into a 
human's eyeball subsystem.  It can be used to change what is already  there, but 
it cannot be used to shorten or lengthen a DASD block.  In the  case of an EOF 
block with data length 0, nothing can be done by ZAP to the data  in that 
block because the data field has been formatted as having a zero length  and thus 
there is no data field.  If the data length were greater than 0,  than the 
contents of the data field could be changed, but the data length cannot  be 
changed, e.g., from 3120 to 256 by ZAP.  Whatever data was on the  track to begin 
with is erased when a new R0 is written, or when an EOF block is  written at 
the beginning (which means right after R0, and which is almost always  called 
R1).


As I understood David's American language , he meant security 
exposure, not data recovery possibility. In other words, ZAP can be used 
(or cannot be - that is the question)to disclose data, unformatted, in 
sysprint, etc.  So there is risk a of "quick erase".


Regarding to the original question: I don't know whether ZAP can be used 
for that, but I believe, it is protected by RACF DASDVOL/GDASDVOL class 
profiles. At least VTOC is.

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Bill Fairchild]

 
In a message dated 7/27/2005 9:19:58 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:
 
>I was wondering if ZAP would/not allow one to
>retrieve data from a  track that had been "cleared" by writing R0 or EOF at
>beginning of the  track. I guess Radoslaw Skorupka's English comes out better
>than mine.  Can I blame it on American television? Hmm, no, come to think of
>it.  English is NOT spoken on 'American' television'.

?Anykahow, will ZAP  recover data as asked?




IMASPZAP will not retrieve or recover data, if I understand what I think  you 
mean by those words.  ZAP will only read what is on the track and  format it 
for displaying to the SYSPRINT file, which is typically then read  into a 
human's eyeball subsystem.  It can be used to change what is already  there, 
but 
it cannot be used to shorten or lengthen a DASD block.  In the  case of an EOF 
block with data length 0, nothing can be done by ZAP to the data  in that 
block because the data field has been formatted as having a zero length  and 
thus 
there is no data field.  If the data length were greater than 0,  than the 
contents of the data field could be changed, but the data length cannot  be 
changed, e.g., from 3120 to 256 by ZAP.  Whatever data was on the  track to 
begin 
with is erased when a new R0 is written, or when an EOF block is  written at 
the beginning (which means right after R0, and which is almost always  called 
R1).
 
Bill Fairchild

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[David Speake]

Ooops, I was most unclear. I was wondering if ZAP would/not allow one to
retrieve data from a track that had been "cleared" by writing R0 or EOF at
beginning of the track. I guess Radoslaw Skorupka's English comes out better
than mine. Can I blame it on American television? Hmm, no, come to think of
it. English is NOT spoken on 'American' television'.

Anykahow, will ZAP recover data as asked?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Bill Fairchild]

 
In a message dated 7/27/2005 5:22:39 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:
 
>I very vaguely seem to remember useing SUPERZAP/MVS? (in a ROSCOE  monitor)
>about 20+ years ago to read an entire track, Seems like it read  EVERYTHING,
>Even told me where the EOF markers were. Not an SP and it was  Lng ago.

>?

 




SUPERZAP, aka IMASPZAP, is still with us, and it will display almost  
everything on a track.  It will not display the Home Address or any part of  
R0.  It 
does not display any count fields, but the count fields can be  inferred and 
reconstructed from what it does display.  It does not display  key fields 
unless you trick it with the following JCL:
//SYSLIB DD DSN=my.data.set,DISP=SHR,...,DCB=KEYLEN=255,...,other  parms
This will cause it to display key fields of up to 255 bytes.
 
I can't now remember how the original topic of erasing DASD changed into  
Superzap, so let me add that Superzap will not erase data on a track, only  
change data.  
 
Bill Fairchild

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[David Speake]

I very vaguely seem to remember useing SUPERZAP/MVS? (in a ROSCOE monitor)
about 20+ years ago to read an entire track, Seems like it read EVERYTHING,
Even told me where the EOF markers were. Not an SP and it was Lng ago.

?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Bill Fairchild]

 
In a message dated 6/30/2005 9:52:17 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:

I went  back to check the source code for the program I have for doing this
level  of 'CLEARING' a DASD. It does indeed write a record to allow the DASD 
to
be  used by subsequent users.


Very good.  The way the CKD controllers work is that whenever you have  
written the last piece of data onto a track using a formatting write command,  
the 
rest of the track after that point is erased.  So if all you format  write is 
the home address, then R0 and all the rest of the track is  erased.  If you 
format write the home address and R0 or only R0, then  everything after R0 is 
erased.  Etc.  Later when you want to copy data  onto the track from a backup 
tape, e.g., you have to access R0 before you can do  a format write into R1, so 
if there is no R0 then you can never write R1,  meaning you can't restore the 
track.
 
Bill Fairchild

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Thomas Kern]

I went back to check the source code for the program I have for doing this
level of 'CLEARING' a DASD. It does indeed write a record to allow the DASD to
be used by subsequent users. 

CYL  HD 00 HOME ADDRESS 00 RECORD ZERO 00 00 000800
00 
 
CYL  HD 00 REC 001 COUNT 01 00 

/Tom Kern

--- Bill Fairchild <[EMAIL PROTECTED]> wrote:
> >A re-write of HOME ADDRESS for each track, chaining together I/Os to  
> logically
> >reset 1 3380/3390 cylinder with each I/O might be sufficient in  a DR 
> situation...
> 
> Technically correct, practically not such a good idea, though.  This  will 
> indeed erase all tracks in one cylinder if 15 home address rewrites are 
> chained 
> together per I/O.  But it will also cause massive  problems when the next 
> user tries to unload data onto the tracks, as there will  be no R0 on any of
> the 
> tracks.  You must rewrite Home Address AND R0 in  order to leave the tracks 
> both erased AND also usable by anyone else.  Or  you could simply rewrite
> only 
> the R0 blocks.  If you are going to go to the  trouble to write an ALC
> program 
> to do this, then you might as well skip over the  home address and R0 and 
> write an EOF record where the first record (normally  known as R1) would be. 
> This 
> would reduce channel connect time to a very  low value per track and still 
> erase the rest of the track.
>  
> In order to rewrite the home address and/or R0, the program doing so must  be
> 
> authorized, but it must be authorized anyway if you are going to erase tracks
> 
>  allocated to any users to which the erasing job does not have write  access.
> 
>  The more things like home address and R0 you try to erase, the  more likely 
> you are to hose the track so that no one else can use it until an  ICKDSF 
> fixes it.  It's better to rewrite the R1 block with a very small  piece of
> useless 
> data (one byte of X'00' or an EOF record, e.g.).  You can  hose R1 and the 
> track can still be used by others.
>  
> It's necessary but not sufficient to erase your data.  You must also  leave 
> the tracks in a condition usable by the next user, or you may be asked to 
> find 
> a different DR site next time.
>  
> > where you can trust that the DASD will be reused soon and often before  it 
> gets
> > removed.
>  
> DASD doesn't get removed any more, at least not by any users.  An  engineer 
> might remove one if it needs repair or replacement.


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Bruce Black]

A re-write of HOME ADDRESS for each track, chaining together I/Os to logically
reset 1 3380/3390 cylinder with each I/O might be sufficient in a DR situation
where you can trust that the DASD will be reused soon and often before it gets
removed.

There are easier ways than that.  Since Innovation is now selling 
FDRERASE, I won't get into them, leaving them as an exercise for the 
reader 


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Bill Fairchild]

 
In a message dated 6/30/2005 3:48:28 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:
 
>A re-write of HOME ADDRESS for each track, chaining together I/Os to  
logically
>reset 1 3380/3390 cylinder with each I/O might be sufficient in  a DR 
situation...

>Tom Kern
 


Technically correct, practically not such a good idea, though.  This  will 
indeed erase all tracks in one cylinder if 15 home address rewrites are  
chained 
together per I/O.  But it will also cause massive  problems when the next 
user tries to unload data onto the tracks, as there will  be no R0 on any of 
the 
tracks.  You must rewrite Home Address AND R0 in  order to leave the tracks 
both erased AND also usable by anyone else.  Or  you could simply rewrite only 
the R0 blocks.  If you are going to go to the  trouble to write an ALC program 
to do this, then you might as well skip over the  home address and R0 and 
write an EOF record where the first record (normally  known as R1) would be.  
This 
would reduce channel connect time to a very  low value per track and still 
erase the rest of the track.
 
In order to rewrite the home address and/or R0, the program doing so must  be 
authorized, but it must be authorized anyway if you are going to erase tracks 
 allocated to any users to which the erasing job does not have write  access. 
 The more things like home address and R0 you try to erase, the  more likely 
you are to hose the track so that no one else can use it until an  ICKDSF 
fixes it.  It's better to rewrite the R1 block with a very small  piece of 
useless 
data (one byte of X'00' or an EOF record, e.g.).  You can  hose R1 and the 
track can still be used by others.
 
It's necessary but not sufficient to erase your data.  You must also  leave 
the tracks in a condition usable by the next user, or you may be asked to  find 
a different DR site next time.
 
> where you can trust that the DASD will be reused soon and often before  it 
gets
> removed.
 
DASD doesn't get removed any more, at least not by any users.  An  engineer 
might remove one if it needs repair or replacement.

Bill Fairchild

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Thomas Kern]

A re-write of HOME ADDRESS for each track, chaining together I/Os to logically
reset 1 3380/3390 cylinder with each I/O might be sufficient in a DR situation
where you can trust that the DASD will be reused soon and often before it gets
removed.
 
/Tom Kern

--- Bruce Black <[EMAIL PROTECTED]> wrote:

> >
> >
> >For DR security purposes, format writing any kind of  data will 
> >cause the rest of the track to be erased after the last block is  written 
> >and, when read back by software on the mainframe, the original data will 
> not be 
> >readable.  In this case it doesn't matter if you write two, three,  50, or
> one 
> >block per track of only one byte long.  What matters is you are  doing
> format 
> >writes, as would be the case with DISP=NEW.  Still it will  require one
> whole 
> >revolution's worth of time for each track to be erased. 
> >
> It doesn't necessarily require a revolution.  Depending on how the disk 
> vendor has written their CKD emulation, it may simply be necessary to 
> write info at the beginning of the emulated CKD track (on the FBA disk) 
> indicating that there are no more records on the track.  Residual data 
> may still exist on the rest of the emulated track, but there is no way 
> to access it from the mainframe.  The only way to ensure the complete 
> overwrite is to write a full-track record.
> 
> -- 
> Bruce A. Black
> Senior Software Developer for FDR
> Innovation Data Processing 973-890-7300
> personal: [EMAIL PROTECTED]
> sales info: [EMAIL PROTECTED]
> tech support: [EMAIL PROTECTED]
> web: www.innovationdp.fdr.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 




__ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Bill Fairchild]

 
In a message dated 6/30/2005 10:53:34 A.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:

It  doesn't necessarily require a revolution.  Depending on how the disk  
vendor has written their CKD emulation, it may simply be necessary to  
write info at the beginning of the emulated CKD track (on the FBA disk)  
indicating that there are no more records on the  track.


 
Right.  My brain was obsessing on SLEDs again.  Sorry.  And  if DASD Fast 
Write is in use for the formatting writes, there may even be zero  revolutions 
at 
the time the virtual SLED track is formatted.   Something will have to be 
written on a real FBA later in the case of DFW,  but it will not necessarily be 
a 
full revolution.
 
Bill Fairchild

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Bruce Black]

For DR security purposes, format writing any kind of  data will 
cause the rest of the track to be erased after the last block is  written 
and, when read back by software on the mainframe, the original data will  not be 
readable.  In this case it doesn't matter if you write two, three,  50, or one 
block per track of only one byte long.  What matters is you are  doing format 
writes, as would be the case with DISP=NEW.  Still it will  require one whole 
revolution's worth of time for each track to be erased. 

It doesn't necessarily require a revolution.  Depending on how the disk 
vendor has written their CKD emulation, it may simply be necessary to 
write info at the beginning of the emulated CKD track (on the FBA disk) 
indicating that there are no more records on the track.  Residual data 
may still exist on the rest of the emulated track, but there is no way 
to access it from the mainframe.  The only way to ensure the complete 
overwrite is to write a full-track record.


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Bill Fairchild]

 
In a message dated 6/30/2005 9:27:21 A.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:

Although  some 
intelligence agencies might be willing to put in the effort to  recover 
fragmentary data from such disks, I doubt that corporate espionage  or 
hackers would do so. 



The OP asked about DR sites.  No one is going to remove any hard FBA  or old 
SLED disks from any controllers and take them away to someone with the  proper 
equipment to read data written before it was erased.  There is no  way that 
user (N+1) of a DR site can read user (N)'s data if user N erases it  all by 
using whole track format write chains before leaving the DR site.   But the 
magnetized molecules are there nevertheless for someone with enough  authority 
to 
remove the disks and enough $$ to pay to have an expert decipher  them.  
Corporate espionage normally does not allow for either of these two  
requirements, 
nor does corporate security normally require protection against  these 
possibilities.
 
Bill Fairchild

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Bruce Black]

I'm not an expert, but I doubt whether "regular" SCSI (or FC) 
controller allow you to read track "neighbourhood" or - int other 
words - adjust head position. Nevermind. After you read this data you 
still have problem: what bits are set on because of previous 
recording, and what are because of latest recording, what because of 
pre-previous, etc.
It is extremely hard to get any information from the string of bits, 
because of CRC (or other) coding, RAID-x implementation, emulation of 
CKD, EBCDIC translation, etc. Seems like 10 elements puzzle with 
picture of dark night sky. All the bits are in the same colour . 


Radoslaw, I agree with you (and your English is fine).  Although experts 
on disk technology have told us that it is possible to recover previous 
contents of blocks on a FBA disk with the proper diagnostic equipment, I 
believe that it is extremely unlikely that usable data can be 
recovered.  As you say, there will be missing (unrecoverable) data, 
format issues, etc, not to mention interpretation of the data if it is 
not in nice simple EBCDIC (binary and packed data).  Although some 
intelligence agencies might be willing to put in the effort to recover 
fragmentary data from such disks, I doubt that corporate espionage or 
hackers would do so. 


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[R.S.]

Mike Bell wrote:


Actually, it doesn't require a microscope.  All current hard drives
adjust the track location to compensate for expansion of the platter
because the temperature has changed and other little details.  What is
required is a diagnostic controller that can adjust the head position
just to the side of the track so it can read prior data.  Some of what
can be read in relatively short time is close to magical.


I'm not an expert, but I doubt whether "regular" SCSI (or FC) controller 
allow you to read track "neighbourhood" or - int other words - adjust 
head position. Nevermind. After you read this data you still have 
problem: what bits are set on because of previous recording, and what 
are because of latest recording, what because of pre-previous, etc.
It is extremely hard to get any information from the string of bits, 
because of CRC (or other) coding, RAID-x implementation, emulation of 
CKD, EBCDIC translation, etc. Seems like 10 elements puzzle with 
picture of dark night sky. All the bits are in the same colour .



Disclaimer: Forgive me my poor English.


--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Bill Fairchild]

 
In a message dated 6/29/2005 3:44:51 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:

>From the  mainframe CCW point-of-view, once you write over a track, the 
previous  contents are no longer recoverable. 



Yep yep yep.  For DR security purposes, format writing any kind of  data will 
cause the rest of the track to be erased after the last block is  written 
and, when read back by software on the mainframe, the original data will  not 
be 
readable.  In this case it doesn't matter if you write two, three,  50, or one 
block per track of only one byte long.  What matters is you are  doing format 
writes, as would be the case with DISP=NEW.  Still it will  require one whole 
revolution's worth of time for each track to be erased.   But with clever 
programming many, many such tracks can be erased simultaneously  on different 
devices.  The OP was concerned about security in a DR  situation and not top 
secret clearance sanitizing the data so that even  Mission Impossible people 
couldn't read it.
 
Bill Fairchild

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Bruce Black]

The precise location of recorded bits around the track moves around  
somewhat.  That is why the controller does something called "read with  offset" when 
re-reading a block that produced a data check (aka "head  shaking").  The 
read-write mechanism/transducer is moved a tiny distance to  the left of the center 
of where the track is supposed to be, the data is read,  if still bad then 
the transducer is moved a tiny distance to the right of the  center...  If the 
data cannot be read correctly (i.e., no data check  indication) and you have 
moved the transducer so far to either side that it is  now within the tolerance 
for the adjacent track, then you give up on reading  that block.


Another issue is residual magnetism.  When you magnetize a substance,  a 
large % of the molecules are aligned in a certain way.  When you erase  that data, 
not all the molecules get realigned back to their original  direction.  This 
is why skilled recording experts with expensive, sensitive  equipment can 
recover recorded data that was over-written or erased.  The  cost of such recovery 
is high.  The cost of erasing data to the point that  it cannot be recovered 
by an expert is also high.  The trade-off is how  valuable is the data to you 
and what would it cost you if someone else got the  data.


Don't forget that none of the above can be done from the mainframe.  To 
do these actions, someone must remove the FBA disks from the mainframe 
disk subsystem, attach them to a SCSI/Fiber channel with an appropriate 
PC or equipment, and then execute the proper diagnostic command to try 
and read the residual data.  What you will get is the data that the 
mainframe CU emulator wrote on the FBA disk, including emulated count 
fields and such, which varys by manufacturer.   Just makes the job of 
someone trying to recover your data more difficult. 

From the mainframe CCW point-of-view, once you write over a track, the 
previous contents are no longer recoverable. 


Bruce Black

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
06/28/2005
   at 03:44 PM, Gabe Torres <[EMAIL PROTECTED]> said:

>Is the List aware of any other Vendors or products that offer a
>solution ($$) to writing over DASD at a DR site?

It's more difficult for virtual DASD. I doubt that there is a general
solution.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Mike Bell]

Actually, it doesn't require a microscope.  All current hard drives
adjust the track location to compensate for expansion of the platter
because the temperature has changed and other little details.  What is
required is a diagnostic controller that can adjust the head position
just to the side of the track so it can read prior data.  Some of what
can be read in relatively short time is close to magical. The multiple
pass requirement is so the head position is at different parts of the
track tolerance which will reduce the ability of a diagnostic
controller to easily read the data.  Note - this does not make it
impossible just harder.  and yes the electron microscope is still the
final recovery tool.

That is the reason for the requirement for physical destruction for
some kinds of data.

Mike

On 6/29/05, R.S. <[EMAIL PROTECTED]> wrote:
> SArnett wrote:
> 
> > Just out of curiosity, why multiple passes.  I know that they must have
> > their reasons...  Something like residual data on the edges of the track
> > or some such, since there is a possibility of the track not being
> > recorded in the exact location of the previous write?
> 
> It is (theoretically) possible to read "traces" or "remains" from disk
> plate. It is analog device, magnetism is not 0 or 1, sometimes it can be
> 0.05 (it suggest 1 before the erasure), or 0 at the middle of the track,
> but 1 on the edges.
> Lats but not least, it is virtually impossible to read overwritten data
> using regular controller (microscopes are used), it is rather "most
> probable" track content rather then just track content, it is vry
> hard work to assemble the bits into any informative string of data.
> However it is possible.
> IMHO more possible would be to corrupt any employee having access to
> data. And much less expensive.
>  From the other hand "special" agencies like NSA (where it would be much
> harder to corrupt employee or employee cannot steal the data) for sure
> uses their owne erasure methods or just destroy the disks.
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 


-- 
Mike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Bill Fairchild]

 
In a message dated 6/29/2005 9:24:24 A.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:

Just out of  curiosity, why multiple passes.  I know that they must have 
their  reasons...  Something like residual data on the edges of the track 
or  some such, since there is a possibility of the track not being 
recorded in  the exact location of the previous write?




The precise location of recorded bits around the track moves around  
somewhat.  That is why the controller does something called "read with  offset" 
when 
re-reading a block that produced a data check (aka "head  shaking").  The 
read-write mechanism/transducer is moved a tiny distance to  the left of the 
center 
of where the track is supposed to be, the data is read,  if still bad then 
the transducer is moved a tiny distance to the right of the  center...  If the 
data cannot be read correctly (i.e., no data check  indication) and you have 
moved the transducer so far to either side that it is  now within the tolerance 
for the adjacent track, then you give up on reading  that block.
 
Another issue is residual magnetism.  When you magnetize a substance,  a 
large % of the molecules are aligned in a certain way.  When you erase  that 
data, 
not all the molecules get realigned back to their original  direction.  This 
is why skilled recording experts with expensive, sensitive  equipment can 
recover recorded data that was over-written or erased.  The  cost of such 
recovery 
is high.  The cost of erasing data to the point that  it cannot be recovered 
by an expert is also high.  The trade-off is how  valuable is the data to you 
and what would it cost you if someone else got the  data.
 
Here are the DoD's standards:  
_http://72.14.207.104/search?q=cache:dRHWf5Fg2LQJ:security.ouhsc.edu/docs/DoD_5220.doc+DoD+5220&hl=en_
 
(http://72.14.207.104/search?q=cache:dRHWf5Fg2LQJ:security.ouhsc.edu/docs/DoD_5220.doc+Do
D+5220&hl=en) 
 
On the line that says non-removable rigid disk it says that in order to  
clear the data all you need to do is to overwrite all addressable locations 
with  
a single character, such as writing a full track of X'00'.  But in order to  
"sanitize" the disk you must degauss the disk, destroy the disk, or use process 
 "d", which means to Overwrite all addressable  locations with a character, 
its complement, then a random character and  verify.  This would require at 
least 4 revolutions of the track, the first  3 of which are writing and the 4th 
is reading, then some CPU time to do the  verify.  So if it takes X hours to 
download the data and you want it  sanitized, it will take 4X hours to sanitize.
 
Bill  Fairchild

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[R.S.]

SArnett wrote:

Just out of curiosity, why multiple passes.  I know that they must have 
their reasons...  Something like residual data on the edges of the track 
or some such, since there is a possibility of the track not being 
recorded in the exact location of the previous write?


It is (theoretically) possible to read "traces" or "remains" from disk 
plate. It is analog device, magnetism is not 0 or 1, sometimes it can be 
0.05 (it suggest 1 before the erasure), or 0 at the middle of the track, 
but 1 on the edges.
Lats but not least, it is virtually impossible to read overwritten data 
using regular controller (microscopes are used), it is rather "most 
probable" track content rather then just track content, it is vry 
hard work to assemble the bits into any informative string of data.

However it is possible.
IMHO more possible would be to corrupt any employee having access to 
data. And much less expensive.
From the other hand "special" agencies like NSA (where it would be much 
harder to corrupt employee or employee cannot steal the data) for sure 
uses their owne erasure methods or just destroy the disks.


--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Bill Fairchild
> Sent: Wednesday, June 29, 2005 8:50 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Other DASD Erase programs
> 
> 
>  
> In a message dated 6/29/2005 8:26:11 A.M. Central Daylight Time,  
> [EMAIL PROTECTED] writes:
> 
> Write  one of your own.  Use ICKDSF to overlay the VTOC and 
> then use an 
> ALC  program to do two passes of writing two blocks per track of low 
> values and  three blocks per track of low values(to nail that pesky 
> interrecord cap  left by the first one).  It takes about the 
> same amount 
> of time as  DFDSS's erase.  If you can figure out how to 
> write full track  
> records, then you can do it in one pass.  I am still trying 
> to figure  
> that one out.
> 

What "inter record gap"? Remember that 99.999% of all DASD out there is
really FBA behind the scenes. There is no "inter record gap" unless you
are still running SLEDs.

Also remember that anybody using the STK DASD that does that funny
mapping (log structured?) is going to be surprised that the backend may
still have the raw data on it because rewriting a track allocates a new
physical track and does not overwrite the old data.

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[SArnett]

Just out of curiosity, why multiple passes.  I know that they must have 
their reasons...  Something like residual data on the edges of the track 
or some such, since there is a possibility of the track not being 
recorded in the exact location of the previous write?


Bill Fairchild wrote:

I assume you are using QSAM on the 2 and 3 blocks per track pass to make  the 
ALC program easier to write, but a single full-track block can be written  
with EXCP if you want to go there - takes a little more ALC programming.   Chain 
enough full-track writes together to do one whole cylinder per I/O  request.  
Then you lose minimal time due to extra rotations when switching  from one 
track to the next.


BIG CAVEAT:  make sure there are no data sets in use on the volume  before 
you start erasing it.  Especially system data sets.  Especially  JES checkpoint 
and paging data sets.  Been there, done that, got major ugly  scars (master 
console went SOLID red with undeletable critical error msgs just  before system 
crashed bigtime).  ENQ is a good way to test for most  data sets.


High-speed erase of huge number of volumes (such as in a DR facility after  
testing one's DR plan) is a difficult problem, and very necessary.  Whoever  
comes into the DR shop after you leave can see all your data unless you erase it 
when you are finished with your test.  And that includes paging data sets,  
which also need to be erased, but you really ought to do them last.  A  
non-MVS standalone process is probably best (as in New Era).  How to erase  is not 
itself difficult, but how to erase super-fast a huge number of volumes  becomes 
the problem.  One way to speed it up is to ask different DASD  vendors for 
their proprietary full-volume erase command.  STK has one, and  doing one I/O 
request erases the whole volume.  Other vendors may require  doing full-track 
writes to tens of thousands of tracks, a very time-consuming  process.  And 
DoD/IC [1] standards require multiple passes with special bit  patterns.


If it takes you one hour to download all your data at the beginning of a DR  
test shot, plan on taking at least one hour to erase everything.  Test it  all 
at home before you go to the DR place, too.  Then you can accurately  plan on 
how long it will take to erase at the DR place.


Bill Fairchild

[1] Department of Defense/Intelligence Community

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Bill Fairchild]

 
In a message dated 6/29/2005 8:26:11 A.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:

Write  one of your own.  Use ICKDSF to overlay the VTOC and then use an 
ALC  program to do two passes of writing two blocks per track of low 
values and  three blocks per track of low values(to nail that pesky 
interrecord cap  left by the first one).  It takes about the same amount 
of time as  DFDSS's erase.  If you can figure out how to write full track  
records, then you can do it in one pass.  I am still trying to figure  
that one out.


I assume you are using QSAM on the 2 and 3 blocks per track pass to make  the 
ALC program easier to write, but a single full-track block can be written  
with EXCP if you want to go there - takes a little more ALC programming.   
Chain 
enough full-track writes together to do one whole cylinder per I/O  request.  
Then you lose minimal time due to extra rotations when switching  from one 
track to the next.
 
BIG CAVEAT:  make sure there are no data sets in use on the volume  before 
you start erasing it.  Especially system data sets.  Especially  JES checkpoint 
and paging data sets.  Been there, done that, got major ugly  scars (master 
console went SOLID red with undeletable critical error msgs just  before system 
crashed bigtime).  ENQ is a good way to test for most  data sets.
 
High-speed erase of huge number of volumes (such as in a DR facility after  
testing one's DR plan) is a difficult problem, and very necessary.  Whoever  
comes into the DR shop after you leave can see all your data unless you erase 
it 
 when you are finished with your test.  And that includes paging data sets,  
which also need to be erased, but you really ought to do them last.  A  
non-MVS standalone process is probably best (as in New Era).  How to erase  is 
not 
itself difficult, but how to erase super-fast a huge number of volumes  becomes 
the problem.  One way to speed it up is to ask different DASD  vendors for 
their proprietary full-volume erase command.  STK has one, and  doing one I/O 
request erases the whole volume.  Other vendors may require  doing full-track 
writes to tens of thousands of tracks, a very time-consuming  process.  And 
DoD/IC [1] standards require multiple passes with special bit  patterns.
 
If it takes you one hour to download all your data at the beginning of a DR  
test shot, plan on taking at least one hour to erase everything.  Test it  all 
at home before you go to the DR place, too.  Then you can accurately  plan on 
how long it will take to erase at the DR place.
 
Bill Fairchild
 
[1] Department of Defense/Intelligence Community

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[SArnett]

Write one of your own.  Use ICKDSF to overlay the VTOC and then use an 
ALC program to do two passes of writing two blocks per track of low 
values and three blocks per track of low values(to nail that pesky 
interrecord cap left by the first one).  It takes about the same amount 
of time as DFDSS's erase.  If you can figure out how to write full track 
records, then you can do it in one pass.  I am still trying to figure 
that one out.


Gabe Torres wrote:


Hello List,
I have gleaned the Archives on this subject, and have found NEW ERA's
FAST DASD ERASE, and  IBM's DFDSS, ICKDSF and IEBDG. 


Is the List aware of any other Vendors or products that offer a solution
($$) to writing over DASD at a DR site?
Our Budget and Accounting processes expect more than one Vendor Review.
(..hhh Gov'mnt!)

TIA,
Gabe Torres - Systems Programmer
State of Nevada 
Dept of Information Technology - Computing Div. 
This communication, including any attachments, may contain confidential

information and is intended only for the individual or entity to whom it
is addressed. Any review, dissemination or copying of this communication
by anyone other than the intended recipient is strictly prohibited. If
you are not the intended recipient, please contact the sender by reply
e-Mail and delete all copies 




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Ed Gould]

On Jun 28, 2005, at 5:44 PM, Gabe Torres wrote:


Hello List,
 I have gleaned the Archives on this subject, and have found NEW ERA's
FAST DASD ERASE, and  IBM's DFDSS, ICKDSF and IEBDG.

Is the List aware of any other Vendors or products that offer a 
solution

($$) to writing over DASD at a DR site?
Our Budget and Accounting processes expect more than one Vendor Review.
(..hhh Gov'mnt!)

TIA,
Gabe Torres - Systems Programmer
State of Nevada
SNIP-



TRY The FDR People.

Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[Mike Bell]

You mean besides FDR ?
http://www.innovationdp.fdr.com/products/fdrerase/index.cfm

Mike

On 6/28/05, Gabe Torres <[EMAIL PROTECTED]> wrote:
> Hello List,
>  I have gleaned the Archives on this subject, and have found NEW ERA's
> FAST DASD ERASE, and  IBM's DFDSS, ICKDSF and IEBDG.
> 
> Is the List aware of any other Vendors or products that offer a solution
> ($$) to writing over DASD at a DR site?
> Our Budget and Accounting processes expect more than one Vendor Review.
> (..hhh Gov'mnt!)
> 
> TIA,
> Gabe Torres - Systems Programmer
> State of Nevada
> Dept of Information Technology - Computing Div.
>  This communication, including any attachments, may contain confidential
> information and is intended only for the individual or entity to whom it
> is addressed. Any review, dissemination or copying of this communication
> by anyone other than the intended recipient is strictly prohibited. If
> you are not the intended recipient, please contact the sender by reply
> e-Mail and delete all copies
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 


-- 
Mike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

[RACF Expert]

I'd be interested in finding something like that, which can do a secure DOD
erase under z/OS...

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Gabe Torres
Sent: Tuesday, June 28, 2005 17:44
To: IBM-MAIN@BAMA.UA.EDU
Subject: Other DASD Erase programs


Hello List,
 I have gleaned the Archives on this subject, and have found NEW ERA's
FAST DASD ERASE, and  IBM's DFDSS, ICKDSF and IEBDG.

Is the List aware of any other Vendors or products that offer a solution
($$) to writing over DASD at a DR site?
Our Budget and Accounting processes expect more than one Vendor Review.
(..hhh Gov'mnt!)

TIA,
Gabe Torres - Systems Programmer
State of Nevada
Dept of Information Technology - Computing Div.
 This communication, including any attachments, may contain confidential
information and is intended only for the individual or entity to whom it
is addressed. Any review, dissemination or copying of this communication
by anyone other than the intended recipient is strictly prohibited. If
you are not the intended recipient, please contact the sender by reply
e-Mail and delete all copies



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html