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