ADSM-L

Re: mtlib and TSM inventory

2004-10-01 07:57:12
Subject: Re: mtlib and TSM inventory
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 1 Oct 2004 07:58:54 -0400
On Oct 1, 2004, at 4:53 AM, Hashim, Shukrie BSP-ISM/116 wrote:

Hi all,

My TSM inventory shows the following for volume 002491 which is not in
the library:-

                   Volume Name: 002491
             Storage Pool Name: DRMCOPY
             Device Class Name: 3494DEV
       Estimated Capacity (MB): 0.0
                      Pct Util: 0.0
                 Volume Status: Empty
                        Access: Unavailable
        Pct. Reclaimable Space: 0.0
               Scratch Volume?: No
               In Error State?: No
      Number of Writable Sides: 1
       Number of Times Mounted: 0
             Write Pass Number: 0
     Approx. Date Last Written:
        Approx. Date Last Read:
           Date Became Pending:
        Number of Write Errors: 0
         Number of Read Errors: 0
               Volume Location:
Last Update by (administrator): XXXXX
         Last Update Date/Time: 06/03/04 15:09:54

However, mtlib show the following:-

mtlib -l /dev/lmcp0 -f /dev/rmt3 -qD
Device Data:
   mounted volser.............002491
   mounted category...........0000
   device category............012E
   device state...............Device installed in Library.
                              Device available to Library.
                              ACL is installed.
                              Auto Fill is enabled.
   device class...............3590-E1A
   extended device status.....00

I have physically checked the library and there is nothing in the
drive, it is empty.

If TSM knows the volume is not in the library, but the library thinks
it is loaded, how
do I get them back in sync?

"Unavailable" does not mean that the volume is not in the library:
it means only that the volume is defined as unavailable for TSM
use. You should always check your Activity Log for perspective on
the event in which the tape was last used, to help determine what
happened to it.  Perform an mtlib query on the tape volume itself
and see what the library thinks about it.  Check your other drives
to make sure that the tape is not in one of them - which is to say
that it's possible that, over time, drive assignments *could* be
other than you think they are.  If the drive is in the right
position, then it may be defective.  A power cycling may at least
temporarily correct the drive's view of reality, but keep an eye
on that one.

  Richard Sims

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