We've generally seen VCR errors when something happened to the system
while a tape was being written, such as a system crash or drive failure.
Since the tape was not closed properly, the VCR data was not updated.
On the next open, the drive generates an error with FSC=3A2A (bytes
16-17 of the Request Sense data).  About the only way I know of to
prevent ADSM from trying to recover the volume is to cycle through the
volumes outside of ADSM.  However, for a large 3590 storage pool, this
could be prohibitive (it would effectively tie up 1 3590 drive for a
full day just to mount and dismount our volumes).  We don't see enough
VCR errors to take any special action, other than monitoring ANR8776W
messages via a script.

You might look at the help message for ANR8776W as if offers suggestions
on recovering tapes with VCR problems.

>
> Help! I am being plagued by a host of ANR8820Ws (Repairing VCR data for
> tapes on IBM 3590 drives).
>
> I hate these - the "repair" operation takes too long and doesn't always work
> (I've been waiting 10 minutes now for a repair to complete!).  And each
> incident seems to dump about four messages into the error log, claiming
> everything from the tape drive is broken (but the CEs say the drives pass
> all diagnostics) to that the drive is dirty (we clean each drive daily and
> our mount count isn't particularly high).
>
> It has been so bad that in two cases I had to delete a primary storage pool
> volume with discard=yes because the volume had become unreadable before it
> could be copied to copypools.  As you can imagine, this really annoyed me -
> we lost data (of course, I destroyed the tape volumes afterwards, but it
> wasn't nearly satisfying enough). There needs to be a write-verify mode
> which makes sure that the data in a tape-based primary storage pool is
> readable during client backup and storage pool migration, or else a multiple
> copy option that simultaneously writes the data to multiple volumes.
>
> Tapes with bad VCR data are generally marked read-only and we periodically
> perform "move data" commands on such volumes.  ADSM automatically returns
> empty volumes to the scratch pool for reuse which seems to work (but haven't
> been keeping a history of read-only volumes). Should we be pulling and
> destroying these volumes instead? What do you all do?
>
> Basically, I never want to see a VCR error - how can I achieve this
> objective (by means other than not looking at the log).
>
> Thanks,
> Jim
>


--
Tom Bell                                    tom.bell AT westgeo DOT com
Tom Bell                                    tom.bell AT westgeo DOT com
Western Geophysical                         office:     (713) 689-2203
10001 Richmond, Room 3705                   fax:        (713) 689-2758
Houston, TX  77042                          pager:      (713) 415-0419