>The fix =yes is to correct DB inconsistencies, not repair damaged media or
>bad drives.
True. To add more, from what I know...
(Someone in IBM correct me if my understanding of this is astray.)
The database governs all, and so location of the files on the tape is
necessarily controlled by the current db state. That is to say, Audit Volume
positions to each next file according to db records. At that position, it
expects to find the start of a file it previously recorded on the medium. If
not (as when the tape had been written over), then that's a definite
inconsistency, and eligible for db deletion, depending up Fix. The Audit reads
each file to verify medium readability. (The Admin Guide suggests using it for
checking out volumes which have been out of circulation for some time.) Medium
surface/recording problems will result in some tape drives (e.g., 3590) doggedly
trying to re-read that area of the tape, which will entail considerable time. A
hopeless file will be marked Damaged or otherwise handled according to the Fix
rules. The Audit cannot repair the medium problem: you can thereafter do a
Restore Volume to logically fix things, in TSM terms. ("Tape is tape": woe unto
those who do not use copy storage pools.) Whether the medium itself is bad is
uncertain: there may indeed be a bad surface problem or creasing in the tape;
but it might also be that the drive which wrote it did so without sufficient
magnetic coercivity, or the coercivity of the medium was "tough", or tracking
was screwy back then - in which case the tape may well be reusable. Exercise
via tapeutil or the like is in order.
Audit Volume has additional help these days: the CRCData Stgpool option now in
TSM 5.1, which writes Cyclic Redudancy Check data as part of storing the file.
This complements the tape technology's byte error correction encoding to check
file integrity - particularly in these days of "looser" communication and
disjointed storage, with SAN et al. Refer to the TSM 5.1 Technical Guide
redbook for more info.
Richard Sims, BU
