ADSM-L

[ADSM-L] Sometime returning offsite tapes still can't be checked in a scratch

2008-05-30 01:17:04
Subject: [ADSM-L] Sometime returning offsite tapes still can't be checked in a scratch
From: "Schneider, John" <John.Schneider AT MERCY DOT NET>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 30 May 2008 00:15:42 -0500
Greetings,
    We are running TSM 5.4.2 server on AIX 5.3.  We are in a shared
library environment, with 10 TSM server instances sharing a IBM3584 tape
library, while one TSM server instance acts as the library master.
Occassionally, maybe once every few weeks, we get into a situation where
a tape is reclaimed, then goes into Vaultretrieve.  Then our daily
scripts notify our offsite vendor to return that tape, and moves it to
Courierretrieve.  The tape then becomes a scratch tape, as you can seen
in this actlog:
 
Date/Time            Message
--------------------
----------------------------------------------------------
05/28/2008 06:15:00  ANR2017I Administrator EXTSCRIPT issued command:
MOVE
                      DRMEDIA 040153 TOST=COURIERR W=Y  (SESSION: 79397)
05/28/2008 06:15:00  ANR6683I MOVE DRMEDIA: Volume 040153 was moved from
                      VAULTRETRIEVE state to COURIERRETRIEVE. (SESSION:
79397,
                      PROCESS: 240)
05/28/2008 06:29:48  ANR1341I Scratch volume 040153 has been deleted
from
                      storage pool DRCOPYPOOL. (SESSION: 79452)
05/28/2008 06:29:48  ANR6684I MOVE DRMEDIA: Volume 040153 was deleted.
                      (SESSION: 79452)
 
Something goes wrong, though, because we would expect that the instance
that just scratched the tape would notify the library master.  That must
happen most of the time, because usually the next day the tape comes
back and can be checked back in as a scratch.  But sometimes, we get
this message:
 
05/29/08 16:50:04     ANR8443E CHECKIN LIBVOLUME: Volume 040153 in
library      
                       SUN0092 cannot be assigned a status of SCRATCH.
(SESSION:
                       358188, PROCESS: 745)     
 
from the library master when we try to check in the scratch tapes.  Not
for all the returning scratch tapes either, but just a few.  For some
reason  the library master still thinks the TSM server instance owns the
tape, when that isn't true any longer.  But if we wait a few days, we
can check the tapes in fine.
 
Can somebody tell me why a tape (or small group of tapes) can get
scratched by the owning TSM server, but not scratched by the library
master?  And why does it only happen sometimes?

Best Regards,

John D. Schneider 
Lead Systems Administrator - Storage 
Sisters of Mercy Health Systems 
3637 South Geyer Road 
St. Louis, MO  63127 
Phone: 314-364-3150 
Cell: 314-486-2359 
Email:  John.Schneider AT Mercy DOT net

 
This e-mail contains information which (a) may be PROPRIETARY IN NATURE OR
OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only for the
use of the addressee(s) named above. If you are not the addressee, or the
person responsible for delivering this to the addressee(s), you are notified
that reading, copying or distributing this e-mail is prohibited. If you have
received this e-mail in error, please contact the sender immediately.