Re: ICKDSF Release 16
But Rob, that leaves the data still on disk. What you need to do is DDR the disks to tape, then data security erase the tapes, and then obviously -- restore the erased tapes to the disk. Voila - no more data on disk! Of course you'd need to restore from the data security erased tapes to disk several times to ensure that multiple layers were re-written. For those who read this literally, the above suggestions were written with tongue firmly implanted in cheek - follow this advice, and most of my advice, after careful consideration and then with wild abandon. Failure to do so may cause Your job may vary results. Where's April 1st when you need it!? Mike Walter Hewitt Associates Any opinions expressed herein are certainly mine alone and do not even begin to represent the opinions or policies of Hewitt Associates. Rob van der Heij [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 01/31/2007 05:25 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: ICKDSF Release 16 On 1/31/07, Alan Altmark [EMAIL PROTECTED] wrote: I find lots of information about data security erase for tapes, but not for disks. So, that leaves him the option to DDR from disk to tape, and then security erase those tapes. ;-) Rob The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
Re: ICKDSF Release 16
Reminds me of years ago in a data center in South Dakota that was short on space. When one of our keypunch operators found out that our old 2540 punch/reader would punch cards, she suggested loading all our blank cards to tape and when we needed some, just punch them off the tape... ;-) Lee Mike Walter wrote: But Rob, that leaves the data still on disk. What you need to do is DDR the disks to tape, then data security erase the tapes, and then obviously -- restore the erased tapes to the disk. Voila - no more data on disk! Of course you'd need to restore from the data security erased tapes to disk several times to ensure that multiple layers were re-written. For those who read this literally, the above suggestions were written with tongue firmly implanted in cheek - follow this advice, and most of my advice, after careful consideration and then with wild abandon. Failure to do so may cause Your job may vary results. Where's April 1st when you need it!? Mike Walter Hewitt Associates Any opinions expressed herein are certainly mine alone and do not even begin to represent the opinions or policies of Hewitt Associates. *Rob van der Heij [EMAIL PROTECTED]* Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 01/31/2007 05:25 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: ICKDSF Release 16 On 1/31/07, Alan Altmark [EMAIL PROTECTED] wrote: I find lots of information about data security erase for tapes, but not for disks. So, that leaves him the option to DDR from disk to tape, and then security erase those tapes. ;-) Rob The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. -- Lee Stewart, Senior SE Sirius Computer Solutions Phone: (303) 798-2954 Fax: (720) 228-2321 Email: [EMAIL PROTECTED] Web: www.siriuscom.com
Re: ICKDSF Release 16
Who needs April 1? It is February Fools' Day. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Thursday, February 01, 2007 7:12 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ICKDSF Release 16 But Rob, that leaves the data still on disk. What you need to do is DDR the disks to tape, then data security erase the tapes, and then obviously -- restore the erased tapes to the disk. Voila - no more data on disk! Of course you'd need to restore from the data security erased tapes to disk several times to ensure that multiple layers were re-written. For those who read this literally, the above suggestions were written with tongue firmly implanted in cheek - follow this advice, and most of my advice, after careful consideration and then with wild abandon. Failure to do so may cause Your job may vary results. Where's April 1st when you need it!? Mike Walter Hewitt Associates Any opinions expressed herein are certainly mine alone and do not even begin to represent the opinions or policies of Hewitt Associates. Rob van der Heij [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 01/31/2007 05:25 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: ICKDSF Release 16 On 1/31/07, Alan Altmark [EMAIL PROTECTED] wrote: I find lots of information about data security erase for tapes, but not for disks. So, that leaves him the option to DDR from disk to tape, and then security erase those tapes. ;-) Rob The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
Re: ICKDSF Release 16
Either that or have a MODE(WRITEONLY) option in ICKDSF. Mike Walter [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 02/01/2007 10:12 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: ICKDSF Release 16 But Rob, that leaves the data still on disk. What you need to do is DDR the disks to tape, then data security erase the tapes, and then obviously -- restore the erased tapes to the disk. Voila - no more data on disk! Of course you'd need to restore from the data security erased tapes to disk several times to ensure that multiple layers were re-written. For those who read this literally, the above suggestions were written with tongue firmly implanted in cheek - follow this advice, and most of my advice, after careful consideration and then with wild abandon. Failure to do so may cause Your job may vary results. Where's April 1st when you need it!? Mike Walter Hewitt Associates Any opinions expressed herein are certainly mine alone and do not even begin to represent the opinions or policies of Hewitt Associates. Rob van der Heij [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 01/31/2007 05:25 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: ICKDSF Release 16 On 1/31/07, Alan Altmark [EMAIL PROTECTED] wrote: I find lots of information about data security erase for tapes, but not for disks. So, that leaves him the option to DDR from disk to tape, and then security erase those tapes. ;-) Rob The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
Re: ICKDSF Release 16
We are in the process of 'decommissioning' our mainframe platform (MP3000 runing v/VM 3.1). We formatted all our internal and external DASD (3380s and 3390s) using ICKDSF R16 with the following command: I found this in a recent post by searching the archives at: http://listserv.uark.edu/archives/ibmvm.html Look at ICKDSF TRKFMT FROMRANGE(0,0) ERASEDATA CYCLES(n). It writes a special pattern (as opposed to binary zeroes, I guess). Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: ICKDSF Release 16
After reviewing the DoD specifications for destruction by overwriting, I would say that your method does not meet them. Specifications are available here: http://www.tricare.mil/tmis_new/ia/02%20-%20Sanitization.pdf , section 3.1.2. They specify that you must overwrite with a pattern, then the complement of the pattern, then with random data. They further specify that you must overwrite the entire disk, independent of any BIOS or firmware capacity that the system may have. Among other things. My question would be, do you really need to meet DoD specifications? If so, you'll probably need something like FDRERASE, which is certified to meet those specifications. Original Message Subject: ICKDSF Release 16 From: Cliff Brenner [EMAIL PROTECTED] Date: Wed, January 31, 2007 4:03 pm To: IBMVM@LISTSERV.UARK.EDU Hi Folks, We are in the process of 'decommissioning' our mainframe platform (MP3000 runing v/VM 3.1). We formatted all our internal and external DASD (3380s and 3390s) using ICKDSF R16 with the following command: CPVOLUME FORMAT UNIT(nnn) NOVERIFY VOLID(Lnnn) - where nnn is the real pack address We formatted most of the packs on VM, then shut down the system and formatted the CP-owned packs using ICKDSF standalone. Now that the work is done, we are getting questions as to whether ICKDSF formatting conforms to certain Department of Defense standards which recommends multiple formats to guarantee all data has been removed. The ICKDSF manual reads that CPVOLUME FORMAT writes CP information to cylinder 0 and then lays out 4K pages on the remaining cylinders. Does anyone know whether this means 4K pages comprising of binary zeroes? Since our DASD are CKD, what happens to any tracks (if any) that don't fall into 4K boundaries? Is formatting a pack once good enough to insure all data is irrecoverable? Any assistance with these questions would be greatly appreciated. Thank you. Cliff Brenner Pace University Computer Systems Dept.
Re: ICKDSF Release 16
I think it varies the pattern for each cycle. IIRC (memories from the 'nam days) the number of cycles had to be at least 8 for any magnetic media that had anything classified written on it at any time. The CAD folks claimed to be able to recover information from several levels deep at that time, so 8 = several + some undisclosed constant. (Did the intelligence services of 1967 presage the vertical recording of today?) If there was nothing classified on the disks the rules were relaxed. You need to use current rules to determine the number of cycles. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ed Zell Sent: Wednesday, January 31, 2007 1:14 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ICKDSF Release 16 We are in the process of 'decommissioning' our mainframe platform (MP3000 runing v/VM 3.1). We formatted all our internal and external DASD (3380s and 3390s) using ICKDSF R16 with the following command: I found this in a recent post by searching the archives at: http://listserv.uark.edu/archives/ibmvm.html Look at ICKDSF TRKFMT FROMRANGE(0,0) ERASEDATA CYCLES(n). It writes a special pattern (as opposed to binary zeroes, I guess). Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: ICKDSF Release 16
Hi Dave, Thanks for your reply. I received a message from Ed Zell re: the ICKDSF TRKFMT command, which allows for an overwrite of special patterns a specified number of times. Do you know if that would serve the same function as FDRERASE? Cliff After reviewing the DoD specifications for destruction by overwriting, I would say that your method does not meet them. Specifications are available here: http://www.tricare.mil/tmis_new/ia/02%20-%20Sanitization.pdf , section 3.1.2. They specify that you must overwrite with a pattern, then the complement of the pattern, then with random data. They further specify that you must overwrite the entire disk, independent of any BIOS or firmware capacity that the system may have. Among other things. My question would be, do you really need to meet DoD specifications? If so, you'll probably need something like FDRERASE, which is certified to meet those specifications. Original Message Subject: ICKDSF Release 16 From: Cliff Brenner [EMAIL PROTECTED] Date: Wed, January 31, 2007 4:03 pm To: IBMVM@LISTSERV.UARK.EDU Hi Folks, We are in the process of 'decommissioning' our mainframe platform (MP3000 runing v/VM 3.1). We formatted all our internal and external DASD (3380s and 3390s) using ICKDSF R16 with the following command: CPVOLUME FORMAT UNIT(nnn) NOVERIFY VOLID(Lnnn) - where nnn is the real pack address We formatted most of the packs on VM, then shut down the system and formatted the CP-owned packs using ICKDSF standalone. Now that the work is done, we are getting questions as to whether ICKDSF formatting conforms to certain Department of Defense standards which recommends multiple formats to guarantee all data has been removed. The ICKDSF manual reads that CPVOLUME FORMAT writes CP information to cylinder 0 and then lays out 4K pages on the remaining cylinders. Does anyone know whether this means 4K pages comprising of binary zeroes? Since our DASD are CKD, what happens to any tracks (if any) that don't fall into 4K boundaries? Is formatting a pack once good enough to insure all data is irrecoverable? Any assistance with these questions would be greatly appreciated. Thank you. Cliff Brenner Pace University Computer Systems Dept.
Re: ICKDSF Release 16
There are at least two potential problems with using FDRERASE. The first is that it REQUIRES a z/OS (maybe OS/390) operating system to run it. This i s not too much of a problem at a Disaster Recovery vendor site but not easy when you are decommissioning your only mainframe. The second problem is t hat some government agencies have chosen to re-interpret DOD guidelines/specifications to be a triple-pass of random data, random data and a known pattern. It may be just as good, but it isn't exactly what ou r security management wants, and this kind of legalistic landmines is the k ind that will HURT you at the worst time. I would love a standalone version of FDRERASE and an option for any versi on of FDRERASE that would let me specify pattern(random,random,x5a5a). /Tom Kern On Wed, 31 Jan 2007 14:34:15 -0700, Dave Reinken [EMAIL PROTECTED] wrote : After reviewing the DoD specifications for destruction by overwriting, I would say that your method does not meet them. Specifications are available here: http://www.tricare.mil/tmis_new/ia/02%20-%20Sanitization.pdf , section 3.1.2. They specify that you must overwrite with a pattern, then the complement of the pattern, then with random data. They further specify that you must overwrite the entire disk, independent of any BIOS or firmware capacity that the system may have. Among other things. My question would be, do you really need to meet DoD specifications? If so, you'll probably need something like FDRERASE, which is certified to meet those specifications.
Re: ICKDSF Release 16
I worked for CAD for a number of years and they NEVER returned used DASD (HDA's in those days) back to the vendor. They were physically destroyed. - Judson West Teradata, a division of NCR Corporation -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, January 31, 2007 1:37 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ICKDSF Release 16 I think it varies the pattern for each cycle. IIRC (memories from the 'nam days) the number of cycles had to be at least 8 for any magnetic media that had anything classified written on it at any time. The CAD folks claimed to be able to recover information from several levels deep at that time, so 8 = several + some undisclosed constant. (Did the intelligence services of 1967 presage the vertical recording of today?) If there was nothing classified on the disks the rules were relaxed. You need to use current rules to determine the number of cycles. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ed Zell Sent: Wednesday, January 31, 2007 1:14 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ICKDSF Release 16 We are in the process of 'decommissioning' our mainframe platform (MP3000 runing v/VM 3.1). We formatted all our internal and external DASD (3380s and 3390s) using ICKDSF R16 with the following command: I found this in a recent post by searching the archives at: http://listserv.uark.edu/archives/ibmvm.html Look at ICKDSF TRKFMT FROMRANGE(0,0) ERASEDATA CYCLES(n). It writes a special pattern (as opposed to binary zeroes, I guess). Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: ICKDSF Release 16
This may sound crazy but if you really have to meet DOD standards, and if your equipment is old and has no real value, it may be cheaper and faster to remove the disks out of the system and have them destroyed by a certified company. On Wed, 31 Jan 2007 16:03:56 -0500 Cliff Brenner said: Hi Folks, We are in the process of 'decommissioning' our mainframe platform (MP3000 runing v/VM 3.1). We formatted all our internal and external DASD (3380s and 3390s) using ICKDSF R16 with the following command: CPVOLUME FORMAT UNIT(nnn) NOVERIFY VOLID(Lnnn) - where nnn is the real pack address We formatted most of the packs on VM, then shut down the system and formatted the CP-owned packs using ICKDSF standalone. Now that the work is done, we are getting questions as to whether ICKDSF formatting conforms to certain Department of Defense standards which recommends multiple formats to guarantee all data has been removed. The ICKDSF manual reads that CPVOLUME FORMAT writes CP information to cylinder 0 and then lays out 4K pages on the remaining cylinders. Does anyone know whether this means 4K pages comprising of binary zeroes? Since our DASD are CKD, what happens to any tracks (if any) that don't fall into 4K boundaries? Is formatting a pack once good enough to insure all data is irrecoverable? Any assistance with these questions would be greatly appreciated. Thank you. Cliff Brenner Pace University Computer Systems Dept.
Re: ICKDSF Release 16
Thanks for your reply. I received a message from Ed Zell re: the ICKDSF TRKFMT command, which allows for an overwrite of special patterns Cliff, Just to be complete, I was quoting from a previous post that I found in the archives that mentioned ICKDSF TRKFMT. I have no experience with it or knowledge of what should be done to wipe out DASD that you are getting rid of. Sorry for not being clear the first time around. Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: ICKDSF Release 16
On Wednesday, 01/31/2007 at 03:57 CST, McKown, John [EMAIL PROTECTED] wrote: Have you looked at SAE? It has a stand-alone ERASE capability. You can even IPL it off of the DVD in the HMC! Or DASD or Tape. I find such products ... interesting. If you look at the S/390 Command Reference for ESS (SHARK), you will find that the ERASE CCW or formatting record 0 of a track are documented to erase data. But when you read what it says about erasure, things get fuzzy. To wit: A record is said to be erased when it is rendered incapable of being read by the commands and facilities normally used for reading recorded data from the device. The manner in which the erase operation is performed is overwriting the record referenced with pad characters and then erasing the remainder of the track. Of course, it uses the word erase in the definition of the operation, so who knows what it will do. Consider, too, that modern drives separate the appearance of ECKD from reality. It can simply mark some metadata that says erased which the microcode will respect. But take the RAID drives out and read them elsewhere, and who knows what you will find. Then there's that nasty word normally used in there. It makes me nervous. And if you have a moving cursor algorithm, rewriting the same record may not, in fact, rewrite the same record. It may get written and then index pointers are updated. I find lots of information about data security erase for tapes, but not for disks. Methinks I must contact a Reverened Engineer to find out what gives these days... Alan Altmark z/VM Development IBM Endicott
Re: ICKDSF Release 16
Hi Ed, I reviewed the TRKFMT parameters you provided in the ICKDSF R16 manual to confirm their function. Thanks to all who have replied to me so far. Please note I no longer have an operating system, so only a standalone utility like ICKDSF would benefit me at this point. Cliff Thanks for your reply. I received a message from Ed Zell re: the ICKDSF TRKFMT command, which allows for an overwrite of special patterns Cliff, Just to be complete, I was quoting from a previous post that I found in the archives that mentioned ICKDSF TRKFMT. I have no experience with it or knowledge of what should be done to wipe out DASD that you are getting rid of. Sorry for not being clear the first time around. Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED]
Re: ICKDSF Release 16
Perfectly clear to me. When you erase a disk, ... you erase it. What else would you do? :-) Precisely why our storage management group does whatever it is that they do to decommission disks and then contracts with the disk manufacturers to destroy them. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Wednesday, January 31, 2007 2:23 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ICKDSF Release 16 On Wednesday, 01/31/2007 at 03:57 CST, McKown, John [EMAIL PROTECTED] wrote: Have you looked at SAE? It has a stand-alone ERASE capability. You can even IPL it off of the DVD in the HMC! Or DASD or Tape. I find such products ... interesting. If you look at the S/390 Command Reference for ESS (SHARK), you will find that the ERASE CCW or formatting record 0 of a track are documented to erase data. But when you read what it says about erasure, things get fuzzy. To wit: A record is said to be erased when it is rendered incapable of being read by the commands and facilities normally used for reading recorded data from the device. The manner in which the erase operation is performed is overwriting the record referenced with pad characters and then erasing the remainder of the track. Of course, it uses the word erase in the definition of the operation, so who knows what it will do. Consider, too, that modern drives separate the appearance of ECKD from reality. It can simply mark some metadata that says erased which the microcode will respect. But take the RAID drives out and read them elsewhere, and who knows what you will find. Then there's that nasty word normally used in there. It makes me nervous. And if you have a moving cursor algorithm, rewriting the same record may not, in fact, rewrite the same record. It may get written and then index pointers are updated. I find lots of information about data security erase for tapes, but not for disks. Methinks I must contact a Reverened Engineer to find out what gives these days... Alan Altmark z/VM Development IBM Endicott
Re: ICKDSF Release 16
On 1/31/07, Alan Altmark [EMAIL PROTECTED] wrote: I find lots of information about data security erase for tapes, but not for disks. So, that leaves him the option to DDR from disk to tape, and then security erase those tapes. ;-) Rob
