> > A process like rewriting data with different patterns is modeled after > traditional technology. We know at least of some DASD subsystems where > the remaining 24 rewrites would not cause writing at the same location > on a disk, and thus not achieve what you meant to do. Those funny > patterns tend to compress very well and thus may postpone rewriting > the actual data for quite some time. These devices also implement > different RAID levels which may have implications w.r.t. traces of > data remaining in the subsystem.
If you have a modern DASD subsystem and you want to throw it away, then you may want to remove the disk drives and destroy them or have them destroyed. It's quick and easy to verify. If you want to get a good price on the second hand market for your subsystem, then obviously you will include the drives, but then you first have to do whatever *you* can to destroy the data before trusting somebody else with it. SE will tell you that (s)he can delete the LUNs (maybe you can do that too), RAID groups etc. and that it is impossible to recreate them by avoiding the format function and in a way so that they point to the same bits of data scattered in random locations on hard drives and cache in exactly the same sequence so that they resemble your DASDs in the end. And (s)he is probably right, but the bottom line is your data is still there unless you wipe it off and SE will be reluctant to spend hours running some low level utility (which I'm sure they have) to erase the disks, especially if they are not paid to do so. So, run your ICKDSF's as many times as you can from as many worker machines as your channels permit and then convince the SE to do everything (s)he can to destroy the data. Other than that, and since the original question was about Shark, use IBM's service mentioned above if you can afford it. Ivica
