>I just found a way to partially recover data on a defective 3590 cartridge.
>Move data and audit volume aborted when processing a specific file.
>Unfortunately, this was very near to the beginning of the tape. So I was
>afraid to lose about 10 GB of data.
>
>I started del vol discard=yes. Then I got a new idea. The discard is a
>background process which can be cancelled. I cancelled it and ran audit
>volume. Everything was fine because the offendig file was deleted!
>
>Unfortunately, 17000 files and 1.7 GB are lost because the idea came too
>late. I should have cancelled the process much earlier. In case you have the
>same problem I hope you will remember this mail and cancel the discard
>process earlier.
>
>Or is there an even better method?

Our employers have made us trustees of our company's data.  It is our
responsibility to safeguard the data in the TSM storage pools, as it may be the
only surviving copy of the data, and may have to be called back.  That is what
the TSM product is all about.  Tape being "tape" (open to the environment and
its surface exposed to mechanical forces) it is essential to employ Backup
Stgpool as soon as possible after the client has sent data to the server, giving
us that second copy, and by virtual of temporal adjacency, allowing us to alert
the client to re-send any data wherein the Backup Stgpool cannot read the
just-written primary tape.  If at some later time the primary tape cannot be
read, the second copy is my assurance.  (And there may be a third, offsite 
copy.)

My odd view is that I have no right to casually destroy data which does not
belong to me, and therefore I take architectural steps to safeguard it.

   Richard Sims, BU