>Hi ADSM-ers!
>Today I encountered I/O errors on a tape. ADSM reported this like this:
>
>ANR8355E I/O error reading label for volume 0371D8 in drive RMT1
>(/dev/rmt1).
>ANR8778W Scratch volume 0371D8 changed to Private Status to prevent
>re-access.
>
>Changed to Private???? Shouldn't ADSM mark the tape read-only???
>How else can I see that there is something wrong with this tape? The only
>way to find this out is to compare the Q VOLUME list with the Q LIBVOL list
>and manually track the differences.
>Is this behavior correct?
>Kindest regards,
>Eric van Loon
Eric,
If these tapes that you are getting these I/O errors on are new tapes,
I believe I have seen these errors before. Are you using a barcode
labeller to label tapes to ADSM? If anyone was watching the operation,
you may want to ask them if they saw whether the tapes that were to
be labelled were actually mounted in the drive to have the label header
written to the tape as well as scanning the barcode. If the above
errors occurred just after a newly-labelled tape was first mounted
in a drive and ADSM was verifying the label, then you may want to check
out the tapes (to clear the library volume inventory of the invalid
entries), then relabel them with checklabel=barcode. An easy way
to do this in an automated library would be:
IF YOU HAVE MORE THAN ONE VOLUME that you are getting these errors
on currently residing in your library, and you don't have a library
that's just so large as to make using the search parameter too time-
consuming, follow the below:
--------------
checkout libvol [libraryname] [volumename] checklabel=no remove=no
checkout libvol [libraryname] [volumename] checklabel=no remove=no
(repeat for each volume to be relabeled)
--------------
You use checklabel=no to avoid having ADSM mount the tape in the drive
You use checklabel=no to avoid having ADSM mount the tape in the drive
to verify its label (so it'll know for certain it's checking out the
correct volume), which would generate the I/O error again. Use remove=
no because you'll want to keep them in the library instead of ejecting
them, so that you can label them all with the search parameter.
Then, you can run the following:
---------------
label libvol [libraryname] search=yes labelsource=barcode checkin=scratch
label libvol [libraryname] search=yes labelsource=barcode checkin=scratch
---------------
DO NOT USE THE OVERWRITE OPTION WITH THIS SYNTAX...hopefully
DO NOT USE THE OVERWRITE OPTION WITH THIS SYNTAX...hopefully
nobody needed that warning.
Use "devtype=3590" if your library is a 3494, but if it is, you shouldn't
do this unless you have a long time ahead with no tape mount requests
required.
----------------------------------
FOR A SINGLE TAPE:
FOR A SINGLE TAPE:
checkout libvol [libraryname] [volumename] checklabel=no
(then respond to the request ID..."q request" to get the 3-digit ID,
then "reply ###" when the tape is ejected to make ADSM think you
removed the tape from the entry/exit port)
Then,
label libvol [libraryname] search=bulk labelsource=barcode checkin=scratch
Use "devtype=3590" if your library is a 3494 and make sure that any tapes
in your convenience port are either already ADSM-labelled or OK to be
ADSM-labelled.
As to why this may have happened in the first place, I don't know a thing
about it. Black voodoo magic. Lazy ADSM. Malicious libraries up to
sequential
shenanigans. Poorly designed highway systems. But if you're getting these
errors on first-use tape mounts of newly-barcode-labelled volumes, the barcode
label may not have been written to the tape itself and it may need to be
relabelled.
Anything I'm overlooking? Hope this helps, Eric.
Regards,
Longshot
|
