ADSM-L

Re: Update - Re: [ADSM-L] Some strange tape related issues?

2006-04-11 04:01:27
Subject: Re: Update - Re: [ADSM-L] Some strange tape related issues?
From: Farren Minns <fminns AT WILEY.CO DOT UK>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 11 Apr 2006 08:52:49 +0100
Hi all

Regarding the fact that the SCRATCHCATegory value for 3590 tapes is the
value of the 3490 tapes plus one, how does TSM cope with this? In my
situation, with the SCRATCHCATegory set to 301(12D), and the Hex value
within the library being 12E(302) surely it should not be able to see the
scratch volumes? What am I missing here?

Also, how do I fix volumes marked FFFA within the library manager? There
are four volumes in my library with this category code.

Two of them are volumes that now do not even exist (one is called 'CLEAN'
and has never existed that I know of). The other two are for copypool
volumes that TSM sees as offsite and I have just checked with the DR site
and these volumes do indeed exist). So how do I tell the library to stop
worrying about these volumes?

I am having a look through the "IBM TotalStorage Enterprise Tape A
Practical Guide", but have not found what I am looking for so far.

Thanks again as always

Farren
|-----------------------------+-------------------------------------------|
|   Richard Sims <rbs AT BU DOT EDU> |                                          
 |
|   Sent by: "ADSM: Dist Stor |                                           |
|   Manager"                  |                                         To|
|   <ADSM-L AT VM.MARIST DOT EDU>    |                 ADSM-L AT VM.MARIST DOT 
EDU      |
|                             |                                         cc|
|   10/04/2006 15:21          |                                           |
|                             |                                    Subject|
|         Please respond to   |                 Re: [ADSM-L] Update - Re: |
|         "ADSM: Dist Stor    |                 [ADSM-L] Some strange tape|
|             Manager"        |                 related issues?           |
|      <ADSM-L AT VM.MARIST DOT EDU> |                                          
 |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|-----------------------------+-------------------------------------------|








On Apr 10, 2006, at 5:46 AM, Farren Minns wrote:

> Hi again
>
> OK, here's something I have just found, and this is on the current
> working
> live server (that has worked this way for years).
>
> When I look at the lib definition within TSM, I see the following :-
>
> Library Name                3494A
> Library Type                349X
> ACS Id                        -
> Private Category        300
> Scratch Category        301
>
> But, when I do a 'mtlib -l 3494a -qI' from the command line I see the
> following (just an example):-
>
> 000212                 FFFA         01 10 00        (this is a
> copypool
> vol)
> 000222                 012E         00 10 00        (this is scratch)
> 000223                 012C         00 10 00        (this is private)
>
> Now, when I punch 300 in to my scientific calculator I get a Hex
> value of
> 12C, and that fits in with the info above.
>
> But, when I enter 301 I get 12D which does not fit in with the
> above 3494
> assignments. So how on earth is this working at all?

Oddly, the explanation for this seems to have evaporated from the TSM
manuals, but is preserved in ADSM QuickFacts. The 3494 started life
as a 3490 tape library, and 3590s ere added later. It became the
convention that the SCRATCHCATegory value was for 3490 tapes, and
that value plus one was for 3590 tapes.

>
> Also, the category FFFA seems to cover copypool volumes that have
> yet to be
> moved from the library and also cleaning tapes. Is this meant to
> work in
> this way?

FFFA is an aberrant state, suggesting that volumes marked that way
were rudely removed from the library without going through the 3494
Library Manager, for it to be aware of what's going on. When it runs
an Inventory, it registers its confusion about the state of the
volumes with that category code value. Refer to Redbook "IBM
TotalStorage Enterprise Tape A Practical Guide" for some info on
that. You need to take action on this inconsistency - which may be
the source of considerable volume access problems.

   Richard Sims


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