This week we had an event where the leader block got pulled off a 3590 tape by
our 3494 tape robot.  (The leader block was found lying on the floor of the
robot's track area, outside the drive - a relatively violent event.)  Rather
than try to reattach the leader block for the duration of a Move Data to get
the data off the tape, I decided to see what a Restore Volume operation was
like.  A preview revealed that 12 copy storage pool tapes would be inputs.
(Our copy storage pool is not collocated; our primary tape pool is.  The
destroyed tape was 17% full.  The non-dedicated server has two 3590 drives.)
    The restore took some 20 hours over three days.  (We had to interrupt it
each day to run DBBackups and other work, reinvoking it to resume during quiet
times.)  It was disconcerting to see ADSM consuming about 20% of an RS/6000
595 processor as it thought for some two hours about the work that it would do
on each next input tape, before mounting and accessing the data on the tape.
Moreover, it left the input and output tapes mounted and "IN USE" for the next
two hours (without I/O) as it pondered the next input tape.  Eventually the
new output tape was 17% full, just like the original. I could only imagine how
much worse this might have been if the destroyed tape were 100% full.  The
manuals fail to give any perspective on how long this can take.
    I researched the ADSM-L archives to get perspective on this and found ADSM
developer Dave Cannon's insightful information from August 8, 1996, well worth
capturing for your ADSM notes.
    In any case, Restore Volume can be a horrendous operation, which I hope
receives redesign in ADSM V.3.  Suffice to say, the next time I have a damaged
tape I will do whatever I can to render the tape usable for the duration of a
Move Data, rather than resort to Restore Volume.
             Richard Sims, Boston University OIT