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.
|
