On Thu, 12 Oct 1995 02:06:09 -0600 Bob Booth - CSO said:
>We have been running an ADSM server with 8MM tapes for quite awhile, but
>we were having quite a few problems with write errors.. So, we decided to
>use 4MM tapes when designing our new server. uhhh... whoops.
Bob,
Don't give up on all your files. We had a problem once with one of our 8mm
tapes. The tape was unreadable in one spot. The MOVE DATA (and I suspect
the RECLAIM process too) process the files on tape sequentially. If it
cannot read a particular file, the process fails to process the remaining
files on that tape. It does not attempt to skip over the bad file. I have
reported this to IBM, and I am expecting (hoping?) that they take an APAR on
this behaviour.
In the meantime, there is a way around the bad spot on tape. You can use
the QUERY CONTENT <volser> command to list the files that are on the tape.
The bad file will be one of the first files listed, but not necessarily the
very first file listed. This is because when ADSM encounters the I/O error,
it backs out the current transaction, which can effect the last few files
that were being moved. This means that the bad file is not necessarily the
first one listed, but it should be one of the first several files listed. I
should qualify this by saying that this is true if the tape errors are
encountered during a MOVE DATA or RECLAIM.
Once you have listed the first dozen or so remaining files on the tape,
the trick is to determine which one is bad, and delete it. If the file
is deleted, then ADSM won't try to move it. Apparently when the MOVE DATA
or RECLAIM process starts up, it indexes to the first file to be moved from
the tape. If this index operation indexes past the bad spot on tape, then
you can get to the remaining files on the tape. The way I did
this was to attempt to recover each file (from the client system). This
may not always be an option, if you don't have access to the client system!
Eventually, you will find a file that cannot be recovered. If this is an
archive file, you can delete it from the client system. This will then
allow the remaining files on the tape to be MOVED/RECLAIMED.
When this happened to us, it was on a tape in an archive storage pool, and
we were able to delete the specific file from the client system. For backup
storage pools, I guess you'd have to delete (or rename) the file on the
client system in such a way that an ADSM expiration process would mark it
as deleted.
Of course, you can also do an AUDIT VOL FIX=YES, but my guess is that this
might cause all the remaining files on the tape to be deleted. This isn't
something you really want to do, except as a last ditch remedy! We did not
have to resort to this, so I can't tell you for sure what would happen.
Regarding the I/O errors: I am suspicious that after adding new tapes to
your library, that more frequent cleanings may be needed. Perhaps new
tapes have garbage on them? I'm not sure, but I think I've seen increased
I/O errors on our 8mm robot after adding new tapes. Sometimes it's hard to
figure out exactly what's going wrong!
Good luck!
..Paul
Paul Zarnowski Phone: 607/255-4757
Cornell Information Technologies Fax: 607/255-6523
Cornell University US Mail: 315 CCC, Ithaca, NY 14853-2601
|
