ADSM-L

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

2008-05-30 10:09:53
Subject: Re: [ADSM-L] Sometime returning offsite tapes still can't be checked in a scratch
From: Anil Maurya <Anil.Maurya AT SANOFI-AVENTIS DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 30 May 2008 10:07:30 -0400
I have seen similar behavior some time. I would suggest run audit
library from library clients ( AUIDT LIBRARY LIBRARYNAME CHECKL=BARCODE
). Make sure no tapes  mounted on library clients. This processes tells
library manager what I own and their status.

THX
 

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Howard Coles
Sent: Friday, May 30, 2008 8:59 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Sometime returning offsite tapes still can't be
checked in a scratch

I'm not sure any of this would affect your situation, but just to cover
some ground and get basic questions out of the way:
1.  Are all the tapes in the same storage pools?
2.  Are there any Reuse delay settings that are different for the tapes
in questions vs those who seem to have no problems?
3.  Are all the tapes being moved from Courier Retrieve in the same
process?  (move drm * wherest=courierr type of thing?)

I don't know that any of these would have the kind of effect that you
are speaking of but, just thought I'd get some of these out of the way.

See Ya'
Howard


> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of Schneider, John
> Sent: Friday, May 30, 2008 12:16 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] Sometime returning offsite tapes still can't be 
> checked in a scratch
> 
> 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.