>Perhaps IBM could add an option to AUDIT VOLUME which would cause all daa
>blocks to be read on the tape?  In the meantime, an AUDIT VOLUME probabl
>does a better job than nothing at all.  My understanding is that for smal
>files, the file data will end up being in the same "tape block" (?) as fle
>header info, so you will end up verifying that the tape block is at leas
>readable (which may be good enough, especially if the tape device has bult-
>in CRC checking).

>I think the only way to guarantee that the tape is still readable is to
>actually do a MOVE DATA on the tape volume.

><=>No, an audit does not guarantee integrity of the data stored on a tape.
><=>I also had this misconception.  An audit validates file information stored
><=>in the database with that stored on the tape.  It does not actually check
><=>to see that the file data itself is readable and correct.  We discovered
><=>this when an audit volume revealed no problems, yet a move data failed.

Paul apparently had an experience in which certain tape defects were detected
by a Move Data command, but went undetected by an Audit Volume.   I don't
have an explanation for why this occurred in this specific situation.

In general, however, the Audit Volume command is a much better way to
check ADSM tapes than Move Data.  The Audit Volume command reads every
byte of every file on the volume and checks control information which the
server imbeds in the file when it is stored.  The same code is used for
reading and checking the file as would be used if the file were to be
restored to a client.  In contrast, Move Data simply copies the file
from one volume to another.

While there may be exceptional situations in which Move Data detects
defects that go undected by Audit Volume, the latter command is
a much more effective way of verifying the integrity of files stored
on an ADSM storage pool volume.

Dave Cannon
ADSM Development