mtlib -l /dev/lmcp0 -q I
will show you the inventory categories for the tapes. You have to
translate it from HEX to check if it matches up with the TSM server categories.
This is probably not your issue, but I will document it here just in
case.
If you see a lot of FFFA, FFFB or FF00, the library might have lost
it's categories. It only happens to us once in a while when the PC in the
library goes very bad, or when an admin accidentally does a "reinventory all"
on the back of the library instead of doing an "update inventory".
Either way, if that happens you can get a listing from TSM with a "q
libvol" and then apply your scratch and private categories back onto the
library with the "mtlib -l /dev/lmcp0 -C -VTAPE -tHEX". It is simple to script.
Ben
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Farren Minns
Sent: Saturday, March 25, 2006 9:50 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re - Tape problem after moving TSM to new server
Hi Richard
Well sadly for now I have had to revert to the old server again for tonights
backups. All I can do now is try and work out exactly what is going on and try
to have some kind of a plan to pre-empt this caveat.
As far as the Private and Scratch category goes, the new settings (within
TSM) were the same as for the old server so I don't think it could be that.
But I will need to go through my current server with a fine tooth comb and pick
out any info I may possibly need.
You mention finding out the category code of volume using the mtlib command. I
know a few mtlib commands that I have been using, but not one that shows the
category?
Also, do you think it would be necessary for me to delete and redefine the
deviceclass just as I did with the lib,drives, paths etc? And, If I did that,
would it trash my tapepool, copypool etc?
Sorry for the all the questions but I'm tearing my hair out. It was all going
so well :-)
Many thanks
Farren Minns
|-----------------------------+-------------------------------------------|
| Richard Sims <rbs AT bu DOT edu> |
|
| | |
| 25/03/2006 15:31 | To|
| | Farren Minns |
| | <fminns AT wiley.co DOT
uk|
| | > |
| | cc|
| | |
| | Subject|
| | Re: Tape problem |
| | after moving TSM to|
| | new server |
| | |
| | |
| | |
| | |
| | |
| | |
|-----------------------------+-------------------------------------------|
On Mar 25, 2006, at 9:59 AM, Farren Minns wrote:
>
> ANR8447E No drives are currently available in library 3494A.
This kind of message is often a conflict involving devclass, made confusing
because the message doesn't say as much as it could.
Generically, it means that TSM thinks there are no drives of the correct *type*
for the media involved. In a 3494, with its Category Codes, it may mean that
the tapes ended up with a Category Code value which differs from those in the
TSM Library definition. In this case, do Query LIBRary and compare the Private
and Scratch categories against what the tapes actually have, as reported via
the mtlib command. Whereas you can mount scratches, it suggests that your
Private category code values may be off. Beyond that, query your devclass
configs and compare to what your full/filling tapes show for devclass.
Whereas you moved to a new Solaris platform, there may be subtle differences in
the drive definitions which are causing problems. Do a SHow LIBRary and compare
against your OS display of tape drive definitions.
Richard
######################################################################
The information contained in this e-mail and any subsequent correspondence is
private and confidential and intended solely for the named recipient(s). If
you are not a named recipient, you must not copy, distribute, or disseminate
the information, open any attachment, or take any action in reliance on it. If
you have received the e-mail in error, please notify the sender and delete the
e-mail.
Any views or opinions expressed in this e-mail are those of the individual
sender, unless otherwise stated. Although this e-mail has been scanned for
viruses you should rely on your own virus check, as the sender accepts no
liability for any damage arising out of any bug or virus infection.
######################################################################
|
