Doug,

Thanks for the suggestion, but that won't really work because it would
move all of the other storage pools as well.  And that is not what I
need to do.

In hindsight, I should have created a device class for each storage
pool.  That is now going to be a part of my standard installation since
it costs very little to do it and can save an awful lot in the long run.

--
Regards,
Mark D. Rodriguez
President MDR Consulting, Inc.

===============================================================================
MDR Consulting
The very best in Technical Training and Consulting.
IBM Advanced Business Partner
SAIR Linux and GNU Authorized Center for Education
IBM Certified Advanced Technical Expert, CATE
AIX Support and Performance Tuning, RS6000 SP, TSM/ADSM and Linux
Red Hat Certified Engineer, RHCE
===============================================================================



Thorneycroft, Doug wrote:

You can update your device class to point to the new library, but
all storage pool using that class will be redirected.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Mark D. Rodriguez
Sent: Friday, December 02, 2005 2:12 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: How do you change the device class of a storage pool?


Hi,

I am not sure this can be done, but here is what I would have to do.

   * Customer currently has one library(libA) with one device class
     (devA) defined that points at libA, and several storage pools that
     use devA.
   * Customer has installed new library (libB) which is identical to libA.
   * I would like to change the device class of the copypool to be devB
     so it uses libB and not libA anymore.
   * The upd stg command does not support updating the device class
     attribute.  I can see why it might not, so it keeps people from
     moving an LTO based storage pool to  say a DLT library.

My solution is:

   * rename copypool to oldcopypool
   * create new copypool using new devB class
   * make sure that all new backup data is to diskpool which I backup
     to copypool prior to migration or any data going straight to
     tapepool must goto copypool at the same time via the "copy storage
     pools" attribute.
   * Then start the lengthy backup of tapepool to copypool.  This means
     every byte in tapepool has to be re-copied to the new copypool.
     In my case this will take about 14 days of non-stop spinning of
     tapes on every drive available!  So for all practical purposes it
     will take me 3-4 weeks since I will have to use the drives for
     production purposes during that time.
   * Once tapepool is backed up to copypool I can start the long
     process of deleting oldcopypool.  I will have to do a del vol
     VOL_NAME discarddata=yes for each volume in the oldcopypool.  This
     will be very IO intensive and will take some time as you can only
     run a couple of these at a time without seriously impact the
     performance of the system.

My question:

Does anybody have a better way to do this?  I am missing something in my
process above that might make things simpler?  This is definitely a time
when I wish I could just poke something into the TSM DB!

Thank You in advance for any help you can offer.

--
Regards,
Mark D. Rodriguez
President MDR Consulting, Inc.

===============================================================================
MDR Consulting
The very best in Technical Training and Consulting.
IBM Advanced Business Partner
SAIR Linux and GNU Authorized Center for Education
IBM Certified Advanced Technical Expert, CATE
AIX Support and Performance Tuning, RS6000 SP, TSM/ADSM and Linux
Red Hat Certified Engineer, RHCE
===============================================================================