Re: ERASEDATA - DASD disposal
Linda Mooney pisze: Greetings! I am in the process of retiring 3 RAMAC 2 racks, each with a 3990 mod 6 controller, and 1 RAMAC 3 rack, with a 9293 controller. All data has been moved to new DASD. The RAMAC DASD will be surplused so I have to be sure that the data has been wiped clean and nothing is recoverable - w ithout physically damaging the devices. All of the DASD is 3390-3. Well... Those dasd arrays are 10+ years old and have zero value. Disks inside also have zero value. So the cheapest method to erase data could be to physically destroy those disks. It is also the most secure method. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
In a message dated 7/6/2009 1:50:12 P.M. Central Daylight Time, barry.a.schw...@boeing.com writes: But even if the space has been allocated to a subsequent file, there is no guarantee that any data was actually written the disk. Think what I did on the ICEBERG-low these many moons was reformat to different geometry a couple of times and called it day. **An Excellent Credit Score is 750. See Yours in Just 2 Easy Steps! (http://pr.atwola.com/promoclk/100126575x1222377077x1201454398/aol?redir=http://www.freecreditreport.com/pm/default.aspx?sc=668072hmpgID=62bcd=Jul yExcfooterNO62) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
Even more insidious are the methods of reading how strongly the magnetized bit is positive or negative. If the bit is on, but not as strongly as others, it might have been off before getting flipped. If very strongly on it might have been reinforced when the 1 bit was written to it. It would take several passes of randomized ones and zeros to fool this technology. Ken Klein Sr. Systems Programmer Kentucky Farm Bureau Insurance - Louisville kenneth.kl...@kyfb.com 502-495-5000 x7011 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gerhard Postpischil Sent: Thursday, July 02, 2009 5:29 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ERASEDATA - DASD disposal Eric Bielefeld wrote: I always wondered if it was possible to read data if binary zeros or some other pattern were written to the disk. I thought that it would be very hard, which the article quoted seemed to agree with. But then, I noticed that the writer of the article didn't sign his name. As I understand it, the magnetized portion of a track is slightly wider than the write head. When a track is rewritten, the head alignment will be slightly different, leaving a little bit of the original track. So what you are writing on subsequent passes doesn't really matter, unless you do it often enough to make it unlikely to retain any trace of the original. And of course there are the newfangled storage boxes where you get a different physical track on every write. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
On Fri, 3 Jul 2009 07:24:02 -0400, Klein, Kenneth wrote: Even more insidious are the methods of reading how strongly the magnetized bit is positive or negative. If the bit is on, but not as strongly as others, it might have been off before getting flipped. If very strongly on it might have been reinforced when the 1 bit was written to it. It would take several passes of randomized ones and zeros to fool this technology. ... or one pass with specialized hardware that overwrites with bits with random amplitude. How consistent is the amplitude in ordinary write amplifiers? And how repeatable is the longitudinal density? Is there any confidence the overwritten bit occupied the same position as the overwriting bit? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
I am in the process of retiring 3 RAMAC 2 racks, each with a 3990 mod 6 controller, and 1 RAMAC 3 rack, with a 9293 controller. All data has been moved to new DASD. The RAMAC DASD will be surplused so I have to be sure that the data has been wiped clean and nothing is recoverable - w ithout physically damaging the devices.  All of the DASD is 3390-3.  It really depends on your definition of Wiped Clean. No amount of passes will get rid of the data where it could not be recovered. Have to measure the worth of the data if someone really, really wanted to recover it. In general the only way to assure it is unrecoverable is a method the military has used. Cut the each platter up in four pieces, take a scenic flight way out over the ocean and scatter the pieces over many square miles of deep water. Do not know if the technique is still in use today or not. Back when we were transferring the equipment between military organizations, 3 passes was acceptable with the agreement that the last one in line who would junk the equipment had to disassemble the drives and phsyically destroy the media. Enjoy jim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
On Thu, Jul 2nd, 2009 at 10:13 PM, Jim Marshall wrote: It really depends on your definition of Wiped Clean. No amount of passes will get rid of the data where it could not be recovered. Have to measure the worth of the data if someone really, really wanted to recover it. My attitude has always been: - your competition has already tried to get your (competitive) data - the police can get it when they want - the spooks already have it. Who are you worried about ?. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
On Tue, 30 Jun 2009 23:36:08 +, Linda Mooney wrote: Do you consider the 4 passes with TRKFMT enough to be sure that the  data is really gone? http://www.h-online.com/security/news/112432 Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
I always wondered if it was possible to read data if binary zeros or some other pattern were written to the disk. I thought that it would be very hard, which the article quoted seemed to agree with. But then, I noticed that the writer of the article didn't sign his name. Eric Bielefeld Sr. Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Norbert Friemel nf.ibmm...@web.de Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@bama.ua.edu Sent: Thursday, July 02, 2009 11:08 AM Subject: Re: ERASEDATA - DASD disposal On Tue, 30 Jun 2009 23:36:08 +, Linda Mooney wrote: Do you consider the 4 passes with TRKFMT enough to be sure that the  data is really gone? http://www.h-online.com/security/news/112432 Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
Thanks, Matthew! I'll have a look at the REVAL Linda - Original Message - From: Matthew Stitt mathwst...@bellsouth.net To: IBM-MAIN@bama.ua.edu Sent: Wednesday, July 1, 2009 3:33:02 PM GMT -08:00 US/Canada Pacific Subject: Re: ERASEDATA - DASD disposal The last time I needed to perform this function, I used the DSF REVAL command. IIRC, it ran fairly quickly compared to your times. And I ran it against multiple device addresses at the same time. Take a look at that command as I believe it resets the disks to factory delivered status. On Wed, 1 Jul 2009 20:37:29 +, Linda Mooney linda.lst...@comcast.net wrote: Hi Barry, Yes , I realize the difference. This is test data, data that is publicly availible through other avenues, including public websites, and old z/OS targ, dlib, and hsf volumes. As you say, p hysical destruction is the most secure, but I am not given that option, nor can I purchase a product. I have to use the tools at hand. I do want to do the best job possible of it, but it has been more than 10 years since I have done this function, so I do appreciate the input and suggestions. Thanks, Linda - Original Message - From: Barry A Schwarz barry.a.schw...@boeing.com To: IBM-MAIN@bama.ua.edu Sent: Wednesday, July 1, 2009 11:57:18 AM GMT -08:00 US/Canada Pacific Subject: Re: ERASEDATA - DASD disposal I hope you realize that nothing is recoverable is very vague.  Most of the time, the phrase means not worth the effort to recover.  If you have security or regulatory issues where the phrase must be taken literally, I know of no options other than physical destruction. -Original Message- From: Linda Mooney [mailto:linda.lst...@comcast.net] Sent: Tuesday, June 30, 2009 4:36 PM To: IBM-MAIN@bama.ua.edu Subject: ERASEDATA - DASD disposal I am in the process of retiring 3 RAMAC 2 racks, each with a 3990 mod 6 controller, and 1 RAMAC 3 rack, with a 9293 controller. All data has been moved to new DASD. The RAMAC DASD will be surplused so I have to be sure that the data has been wiped clean and nothing is recoverable - w ithout physically damaging the devices.  All of the DASD is 3390-3.  -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
Eric Bielefeld wrote: I always wondered if it was possible to read data if binary zeros or some other pattern were written to the disk. I thought that it would be very hard, which the article quoted seemed to agree with. But then, I noticed that the writer of the article didn't sign his name. As I understand it, the magnetized portion of a track is slightly wider than the write head. When a track is rewritten, the head alignment will be slightly different, leaving a little bit of the original track. So what you are writing on subsequent passes doesn't really matter, unless you do it often enough to make it unlikely to retain any trace of the original. And of course there are the newfangled storage boxes where you get a different physical track on every write. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
Gerhard, According to this source, that theory is in question: http://www.h-online.com/security/Secure-deletion-a-single-overwrite-will -do-it--/news/112432 (watch the wrap). Tom Harper IMS Utilities Development Team Neon Enterprise Software Sugar Land, TX -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gerhard Postpischil Sent: Thursday, July 02, 2009 4:29 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ERASEDATA - DASD disposal Eric Bielefeld wrote: I always wondered if it was possible to read data if binary zeros or some other pattern were written to the disk. I thought that it would be very hard, which the article quoted seemed to agree with. But then, I noticed that the writer of the article didn't sign his name. As I understand it, the magnetized portion of a track is slightly wider than the write head. When a track is rewritten, the head alignment will be slightly different, leaving a little bit of the original track. So what you are writing on subsequent passes doesn't really matter, unless you do it often enough to make it unlikely to retain any trace of the original. And of course there are the newfangled storage boxes where you get a different physical track on every write. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
On Thu, 2 Jul 2009 16:49:24 -0500, Tom Harper wrote: Gerhard, According to this source, that theory [track edge residue] is in question: http://www.h-online.com/security/Secure-deletion-a-single-overwrite-will-do-it--/news/112432 (watch the wrap). Thanks. I long wondered, given that disk technology is pushing the physical limits, how one might expect to do orders of magnitude better -- if one can recover the original data, one must be able similarly to recover the content of each intervening random overwrite pattern. The cited article and its followups point out that it's a greater concern to erase all temporary copies of the file (how often do you S(ave) during an E(dit) session?) And that this concern is magnified in RAID systems which intrinsically keep redundant data. I searched Google for ZFS SECURE DELETE, since Time Slider's ability to recover deleted files exaggerates the hazard. The consensus is that ZFS has yet no secure delete facility; an alternative is to keep the data encrypted and destroy the key. (How do you assure that all errant copies of the key are destroyed? Same way you assure that all errant copies of the base data (on laptops, SD cards, etc.) are destroyed.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
At 18:20 -0500 on 07/02/2009, Paul Gilmartin wrote about Re: ERASEDATA - DASD disposal: The cited article and its followups point out that it's a greater concern to erase all temporary copies of the file (how often do you S(ave) during an E(dit) session?) This issue is handled by doing an Erase Free Space via a utility that has that function. All of your Temporary Copies (after the Edit and Save is done) are either now in Free Space or the space they were in has been recycled by being allocated to another file. You can also do a Secure Empty Trash for PC Data that you have moved to the Trash when you empty it (normal Empty just dereferences the files by removing them from the directory and moving their tracks to the Free Space Queue without doing anything to the contents of the tracks). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
Linda, How many concurrent Trkfmt commands are you running? Are you running simultaneous commands against adjacent UCBs? IIRC the Ramac has 2 3390 addresses per drawer sharing the read/write assembly. I would only run 4 commands against addresses that were in unique drawers. Dave O'Brien NIH Contractor From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Linda Mooney [linda.lst...@comcast.net] Sent: Tuesday, June 30, 2009 7:36 PM To: IBM-MAIN@bama.ua.edu Subject: ERASEDATA - DASD disposal Greetings! I am in the process of retiring 3 RAMAC 2 racks, each with a 3990 mod 6 controller, and 1 RAMAC 3 rack, with a 9293 controller. All data has been moved to new DASD. The RAMAC DASD will be surplused so I have to be sure that the data has been wiped clean and nothing is recoverable - w ithout physically damaging the devices. All of the DASD is 3390-3. For the RAMAC2 data wipe I have been using ICKDSF release 17.0 TRKFMT UNITADDRESS(B40) VERIFY(ZSDLZ6) ERASEDATA - CYLRANGE(0,5000) CYCLES(4) That takes about 20 minutes per cycle. Our maintenance vendor recommended 4 cycles. That seems to be proceeding fine. I am having a problem with the RAMAC 3. I tried the same coding with the RAMAC 3 and it took about 5 hours to run (per address) as compared to roughly 1 hour 20 minutes on the RAMAC 2 . All devices are 3390-3, each controller has 4 paths, low system activity generally with no other work on these strings, and the long run time was consistent for several packs on the RAMAC 3. Should I use some other ICKDSF command to wipe the RAMAC3? Any t houghts on why the run time would be so mu ch longer for the RAMAC3? Do you consider the 4 passes with TRKFMT enough to be sure that the data is really gone? TIA, Linda Mooney -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
Hi Dave, I can run 4 concurrent TRKFMT jobs, each against a different drawer in the RAMAC 2 racks and they run fine and finish the 4 cycles in about 1 hr 20 min. The problem is with the RAMAC 3. Even with just one running it's about 5 hours. I have 4 paths online and no other work going to the RAMAC 3. What do you use and how many passes do you make at your shop when you remove DASD? Thanks, Linda - Original Message - From: David W. O'Brien (NIH/CIT) [C] obrie...@mail.nih.gov To: IBM-MAIN@bama.ua.edu Sent: Wednesday, July 1, 2009 2:27:12 AM GMT -08:00 US/Canada Pacific Subject: Re: ERASEDATA - DASD disposal Linda, How many concurrent Trkfmt commands are you running? Are you running simultaneous commands against adjacent UCBs? IIRC the Ramac has 2 3390 addresses per drawer sharing the read/write assembly. I would only run 4 commands against addresses that were in unique drawers. Dave O'Brien NIH Contractor From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Linda Mooney [linda.lst...@comcast.net] Sent: Tuesday, June 30, 2009 7:36 PM To: IBM-MAIN@bama.ua.edu Subject: ERASEDATA - DASD disposal Greetings! I am in the process of retiring 3 RAMAC 2 racks, each with a 3990 mod 6 controller, and 1 RAMAC 3 rack, with a 9293 controller. All data has been moved to new DASD. The RAMAC DASD will be surplused so I have to be sure that the data has been wiped clean and nothing is recoverable - w ithout physically damaging the devices. All of the DASD is 3390-3. For the RAMAC2 data wipe I have been using ICKDSF release 17.0 TRKFMT UNITADDRESS(B40) VERIFY(ZSDLZ6) ERASEDATA - CYLRANGE(0,5000) CYCLES(4) That takes about 20 minutes per cycle. Our maintenance vendor recommended 4 cycles. That seems to be proceeding fine. I am having a problem with the RAMAC 3. I tried the same coding with the RAMAC 3 and it took about 5 hours to run (per address) as compared to roughly 1 hour 20 minutes on the RAMAC 2 . All devices are 3390-3, each controller has 4 paths, low system activity generally with no other work on these strings, and the long run time was consistent for several packs on the RAMAC 3. Should I use some other ICKDSF command to wipe the RAMAC3? Any t houghts on why the run time would be so mu ch longer for the RAMAC3? Do you consider the 4 passes with TRKFMT enough to be sure that the data is really gone? TIA, Linda Mooney -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
I hope you realize that nothing is recoverable is very vague. Most of the time, the phrase means not worth the effort to recover. If you have security or regulatory issues where the phrase must be taken literally, I know of no options other than physical destruction. -Original Message- From: Linda Mooney [mailto:linda.lst...@comcast.net] Sent: Tuesday, June 30, 2009 4:36 PM To: IBM-MAIN@bama.ua.edu Subject: ERASEDATA - DASD disposal I am in the process of retiring 3 RAMAC 2 racks, each with a 3990 mod 6 controller, and 1 RAMAC 3 rack, with a 9293 controller. All data has been moved to new DASD. The RAMAC DASD will be surplused so I have to be sure that the data has been wiped clean and nothing is recoverable - w ithout physically damaging the devices. All of the DASD is 3390-3. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
The definition of ...nothing is recoverable... is in the eye of the beholder and the beholder's regulators. I think PCI requires complete physical destruction (as in shredded, not just smashed or drilled). Your use of the term 'surplused' would imply some governmental context, and that may push you closer to a physical destruction scenario. Good luck. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Linda Mooney Sent: Tuesday, June 30, 2009 6:36 PM To: IBM-MAIN@bama.ua.edu Subject: ERASEDATA - DASD disposal Greetings! I am in the process of retiring 3 RAMAC 2 racks, each with a 3990 mod 6 controller, and 1 RAMAC 3 rack, with a 9293 controller. All data has been moved to new DASD. The RAMAC DASD will be surplused so I have to be sure that the data has been wiped clean and nothing is recoverable - w ithout physically damaging the devices. All of the DASD is 3390-3. For the RAMAC2 data wipe I have been using ICKDSF release 17.0 TRKFMT UNITADDRESS(B40) VERIFY(ZSDLZ6) ERASEDATA - CYLRANGE(0,5000) CYCLES(4) That takes about 20 minutes per cycle. Our maintenance vendor recommended 4 cycles. That seems to be proceeding fine. I am having a problem with the RAMAC 3. I tried the same coding with the RAMAC 3 and it took about 5 hours to run (per address) as compared to roughly 1 hour 20 minutes on the RAMAC 2 . All devices are 3390-3, each controller has 4 paths, low system activity generally with no other work on these strings, and the long run time was consistent for several packs on the RAMAC 3. Should I use some other ICKDSF command to wipe the RAMAC3? Any t houghts on why the run time would be so mu ch longer for the RAMAC3? Do you consider the 4 passes with TRKFMT enough to be sure that the data is really gone? TIA, Linda Mooney NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
Hi Barry, Yes , I realize the difference. This is test data, data that is publicly availible through other avenues, including public websites, and old z/OS targ, dlib, and hsf volumes. As you say, p hysical destruction is the most secure, but I am not given that option, nor can I purchase a product. I have to use the tools at hand. I do want to do the best job possible of it, but it has been more than 10 years since I have done this function, so I do appreciate the input and suggestions. Thanks, Linda - Original Message - From: Barry A Schwarz barry.a.schw...@boeing.com To: IBM-MAIN@bama.ua.edu Sent: Wednesday, July 1, 2009 11:57:18 AM GMT -08:00 US/Canada Pacific Subject: Re: ERASEDATA - DASD disposal I hope you realize that nothing is recoverable is very vague. Most of the time, the phrase means not worth the effort to recover. If you have security or regulatory issues where the phrase must be taken literally, I know of no options other than physical destruction. -Original Message- From: Linda Mooney [mailto:linda.lst...@comcast.net] Sent: Tuesday, June 30, 2009 4:36 PM To: IBM-MAIN@bama.ua.edu Subject: ERASEDATA - DASD disposal I am in the process of retiring 3 RAMAC 2 racks, each with a 3990 mod 6 controller, and 1 RAMAC 3 rack, with a 9293 controller. All data has been moved to new DASD. The RAMAC DASD will be surplused so I have to be sure that the data has been wiped clean and nothing is recoverable - w ithout physically damaging the devices. All of the DASD is 3390-3. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ERASEDATA - DASD disposal
The last time I needed to perform this function, I used the DSF REVAL command. IIRC, it ran fairly quickly compared to your times. And I ran it against multiple device addresses at the same time. Take a look at that command as I believe it resets the disks to factory delivered status. On Wed, 1 Jul 2009 20:37:29 +, Linda Mooney linda.lst...@comcast.net wrote: Hi Barry, Yes , I realize the difference. This is test data, data that is publicly availible through other avenues, including public websites, and old z/OS targ, dlib, and hsf volumes. As you say, p hysical destruction is the most secure, but I am not given that option, nor can I purchase a product. I have to use the tools at hand. I do want to do the best job possible of it, but it has been more than 10 years since I have done this function, so I do appreciate the input and suggestions. Thanks, Linda - Original Message - From: Barry A Schwarz barry.a.schw...@boeing.com To: IBM-MAIN@bama.ua.edu Sent: Wednesday, July 1, 2009 11:57:18 AM GMT -08:00 US/Canada Pacific Subject: Re: ERASEDATA - DASD disposal I hope you realize that nothing is recoverable is very vague.  Most of the time, the phrase means not worth the effort to recover.  If you have security or regulatory issues where the phrase must be taken literally, I know of no options other than physical destruction. -Original Message- From: Linda Mooney [mailto:linda.lst...@comcast.net] Sent: Tuesday, June 30, 2009 4:36 PM To: IBM-MAIN@bama.ua.edu Subject: ERASEDATA - DASD disposal I am in the process of retiring 3 RAMAC 2 racks, each with a 3990 mod 6 controller, and 1 RAMAC 3 rack, with a 9293 controller. All data has been moved to new DASD. The RAMAC DASD will be surplused so I have to be sure that the data has been wiped clean and nothing is recoverable - w ithout physically damaging the devices.  All of the DASD is 3390-3.  -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ERASEDATA - DASD disposal
Greetings! I am in the process of retiring 3 RAMAC 2 racks, each with a 3990 mod 6 controller, and 1 RAMAC 3 rack, with a 9293 controller. All data has been moved to new DASD. The RAMAC DASD will be surplused so I have to be sure that the data has been wiped clean and nothing is recoverable - w ithout physically damaging the devices. All of the DASD is 3390-3. For the RAMAC2 data wipe I have been using ICKDSF release 17.0 TRKFMT UNITADDRESS(B40) VERIFY(ZSDLZ6) ERASEDATA - CYLRANGE(0,5000) CYCLES(4) That takes about 20 minutes per cycle. Our maintenance vendor recommended 4 cycles. That seems to be proceeding fine. I am having a problem with the RAMAC 3. I tried the same coding with the RAMAC 3 and it took about 5 hours to run (per address) as compared to roughly 1 hour 20 minutes on the RAMAC 2 . All devices are 3390-3, each controller has 4 paths, low system activity generally with no other work on these strings, and the long run time was consistent for several packs on the RAMAC 3. Should I use some other ICKDSF command to wipe the RAMAC3? Any t houghts on why the run time would be so mu ch longer for the RAMAC3? Do you consider the 4 passes with TRKFMT enough to be sure that the data is really gone? TIA, Linda Mooney -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
