Sorry to jump on the band wagon, but I have always thought that putting a tape
that has just been replaced by this method back into the scratch pool is a shade
dangerous. It is fairly safe to assume that if a tape has been marked destroyed,
then you (the administrator) would probably prefer the tape not to be used. So
why make it a scratch volume again, and run the risk of ADSM choosing to try to
use the tape again (I know this happens, as I have seen it!) I feel that it 
would
be better to leave the tape in the storage pool it was in, with a new state, 
such
as "Replaced". The administrator could then remove the tape at theit leisure.

Peter Gathercole
Open Systems Administrator

Bruce Elrick wrote:

> "Brazner, Bob" wrote:
> >
> > Two questions:
> >
> > First question: I recently discovered we had lost a single 3590 tape from
> > our primary backup pool.   Per the Admin. Ref., we marked the volume as
> > "destroyed" and then used Restore Stgpool to successfully reconstruct the
> > files.  In looking at the description for Update Volume, it looks like we
> > could have used that, too.  So the question is: would Restore Volume have
> > worked just as well?
> >
> Yes...
> > Second question:  After the Restore Stgpool completed, the destroyed volume
> > still showed up as a libvol in scratch status.    Shouldn't I now do a
> > Delete Volume to permanently remove this lost tape from ADSM?  Or, does
> > ADSM have some other way of knowing to never try to mount this volume
> > again?
>
> You can't do a delete volume because it is not a volume (try q vol X).
>
> As you mentioned, it shows up as a libv, but that is because ADSM still
> thinks it is in the library; destroyed may mean damaged completely,
> damaged partially, or lost.  You can do an audit library to fix that.
>
> Cheers...
> Bruce