Angel,

We "lose" tapes like this occasionally, too.  Usually, it occurs when we
shutdown ADSM while tapes are still mounted in the 3590 drives (in our 3494
library).  For some reason, when ADSM starts up again, ADSM (or the 3494) is
not smart enough to "see" the tapes that are still hanging around in the
drives.  As a result, the startup tape audit flags the tape(s) as not found
resulting in the LIBVOLUME(s) being deleted and the VOLUME(s) being updated
with an ACCESS of UNAVAILABLE.  Here's what I do to correct the situation.

1) Query the ATL to ensure the tape is in the 012C (in use) category.
2) Issue ADSM command: checkin libv 3590tape xxxxxx devt=3590 status=private
checkl=no (your parameters may be different for your ATL, but the important one
is status=private)
3) Issue ADSM command: update vol xxxxxx acc=readw

That's all there is.  There is no need to open the ATL.  Now, your exact
situation could be different.  But I still feel you should be able to use ADSM
and mtlib commands to correct things without have to open the box.  The
important thing to remember is all three objects (VOL, LIBVolume, and ATL) need
to agree with each other.

Bob Brazner


ANGEL BUGARIN writes:
 > Hello everyone. One of our 3590 library is acting up again.
 > When I query the library, it shows all tapes but one. The
 > one tape not displayed is still physically in the slot. I tried to
 > check it out but to no avail. I got the following message:
 >
 > ANR8433E CHECKOUT LIBVOLUME: Volume SH0133 is not
 > present in library 3590LIB0.
 >
 > In the past, the only way I can retrieve the volume was to offline
 > the library and manually pull out the tape.  Then I would audit the
 > library. After that, I was able to checkin any tape and the query
 > would show all tapes.  That was a temporary solution. Since it
 > became more frequent now, I was wondering if anyone knows of
 > a permanent solution.
 >
 > We are currently at 3.1.2.20 on AIX 4.3.2.
 >
 > Any suggestions?
 >
 > Regards,
 > Angel