Justin,

a delayed answer but still an answer.

1. Can we move optical platters out of one library into another ...
Yes, you can but as a whole. You can replace a library with bigger one,
checkout *all* libvolumes from old one, checkin them in new lib and update
device class to point new library. (TSM) volumes will refer to (new
library) libvolumes without problem for all storage pool defined over that
devclass.
You cannot move only single storage pool over new library/devclass - the
<device class> parameter is available only for "def stg" and not for "upd
stg". You obviously cannot move a volume from a storage pool to another
pool - "move data" is made for that purpose (yes, WORMs are really
expensive).

2. ... how are the scratch volumes allocated to storagepools?
Each library is having its own pool of scratch libvolumes. They are not
shared between libraries - can you expect from the robot to pass the
cartridge to other robot :-) Actually robot-robot passing can be made in
some libraries (STK L700e for example) but from TSM point of view both are
one bigger library.
If you have more than one storage pool over one device class then all
stgpools share library scratches.

3. What is the best way to manage this ...
The best way is to buy a single bigger library instead of bean-counting
for few smaller ones, period. There are a lot of models from many vendors
on the market capable for holding more than 100 disks. For example 3995
model C68 can hold up to 258 cartridges and can have model C18 expansion
for another 258.
Only when you reach the limits of a single *large* library you might need
to have second one. Then you will need to spread storage pools over
devclasses/libraries, spread nodes over storage pools, spread storage pool
backups, etc.

4. ... up to 9 optical jukeboxes in the near future.
Install 9 TSM servers, hire 9 TSM admins and 18 operators, contract 9
separate vaults, etc. - at the end head of such a division ought to become
a very important person, he/she will manage more staff than anyone else in
the company :->
For better alternative look p. 3.

Zlatko Krastev
IT Consultant






Justin Derrick <jderrick AT CANADA DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04.03.2003 11:46
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Vol. Mgmt - Scratch Vols & Moving Volumes


Hi TSMers.  =)

My customer is asking me some interesting questions I can't say I
know how to answer - regarding moving volumes and allocation of
scratch volumes across multiple libraries.

The system uses IBM's Content Manager OnDemand product to archive
documents -- which relies on TSM for long-term storage and storage
management.  The questions are fairly straightforward, and any
information the group could bestow would be greatly appreciated.

The questions are quite general, but just to be clear...  I'm running
AIX 4.3.3 on p/Series (6H1) with TSM 4.2.3.0.  Connected to the
server is one LTO library, and currently one 3995 Optical Jukebox
with about 100 optical platters in it.  In the very near future, a
second and third optical jukebox will be added.  Due to the legal
requirements, all data stored on Write-Once (WORM) media.

When the second library is added, the question quickly becomes:

Can we move optical platters out of one library into another, to
spread out the distribution of data, and 'load balance' retrievals
across the additional 6 drives?

My first inclination is to say 'No' because a device class includes
the library as part of it's definition.  Would checking out a volume
from one jukebox and checking it into another jukebox change it's
device class, or merely update the 'library' field in the volume's
record?  I'd try this out now, but I don't have that second jukebox
yet.

I know that the obvious solution is to 'move data' from a number of
volumes to the newly installed jukebox -- and this would be my
recommended solution, if the data weren't stored on expensive WORM
media which apparently cost 80GBP each.

The follow up to that question is this:

If each library has a number of scratch volumes, and a new volume is
required, how are the scratch volumes allocated to storagepools?
Will a storagepool only claim a scratch volume from it's own library?
If there are no scratch volumes in the current library, will it use
one from another library?  What is the best way to manage this
without having to micromanage each jukebox?  We're also trying to
ensure that a copy storagepool for data stored on opticals does *not*
reside in the same jukebox, for redundancy and availability reasons.

There is potential for this system to include up to 9 optical
jukeboxes in the near future.  What questions need to be asked and
decisions need to be made to ensure that the future is maintainable
by mere humans?

As always, thanks in advance for all your assistance and insight.
I've been a subscriber to ADSM-L for over two years now, and find the
collective skills of the list an exceptionally friendly resource for
my toughest questions.  In short...  Thank You.  =)

-JD.