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 <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 04.03.2003 11:46 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] 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.