ADSM-L

Re: 3494 audit library time estimate

2004-02-06 10:11:04
Subject: Re: 3494 audit library time estimate
From: Ben Bullock <bbullock AT MICRON DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 6 Feb 2004 08:10:29 -0700
        Another thing to remember is that the "audit library" command
will not run as long as any tapes are mounted in the library. The
process will sit out there and keep other tapes from being mounted, but
will wait until all current tapes are dismounted by natural means. So, a
long running migration or reclamation AND an audit library command can
hang it up for hours. Something easy to forget.

        We also have the 3494 and in a few cases the "audit library"
would just hang out there and never complete. In those cases, only a
restart of the TSM server software was able to break it loose.

Ben

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Friday, February 06, 2004 5:06 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: 3494 audit library time estimate


>Anyone out there with an IBM 3494 library that has ever performed an 
>"audit library" have any idea how long it should take?  I had about 60 
>tapes that are in the library but TSM refuses to mount them stating 
>that they are unavailable (updated the to read/write and tried to audit

>them).  I reinventoried on the library side, problem still exists so 
>about 6 hours ago, I kicked off a library audit on one of my servers 
>that is attached to the library.  How long should this take?

WHOA!!  First, before anything else, find out what the problem is! You
probably have a library hardware problem, and trying to treat that with
a sofware remedy won't work.  (Keep in mind that 3494 and like advanced
libraries have their own library manager and database for consistency
maintenance. I've had a 3494 for years and have never had any cause to
do an Audit Library.)  Don't blame TSM for not mounting tapes if the
library is not in a condition to service requests.

Begin by looking back in your TSM Activity Log for when this started,
searching on involved volsers.  Look in your Solaris error log for
indications of problems and when they started.  Use the mtlib command to
query the LM for status and see what's up.  Check the state of the
drives in the OS.  Go check the LM panel to see if the drives are in
Available vs. Unavailable state.  See if any drives are powered off,
uncabled, offline, have tapes stuck in them, etc.  Something is wrong
there.

I suspect that you are not running a library monitor, which would alert
you to problems when they happened.  Consider implementing a 3494
monitor based upon the sample program I provide on my web pages.

   Richard Sims,  http://people.bu.edu/rbs

<Prev in Thread] Current Thread [Next in Thread>