I was in this situation about a year ago.  I think the simplest thing to
do is to define a new copypool based on the 3590 device class.  Backup
your primary pools to it & send the tapes offsite.  Then list the volumes
in the 3490 based copypool and issue 'delete volume <volser> discarddata=yes'
for each volume.  Delete the copypool definition when all the volumes have
been deleted.

This method will cause some database expansion as you have to carry
2 copypool pointers for a while.  If you are still growing this doesn't matter;
you get the space back when you delete the old pool but the space will be in
little pieces throughout the db.  If you can't afford the extra db space
you might think of going naked for a while, that is, delete the old copypool 
first then
backup to the new copypool.

There really isn't a "move storagepool" command.


--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <86256817.00668018.00 AT dstsmtp1.dstsystems DOT com>, on 10/27/99
In <86256817.00668018.00 AT dstsmtp1.dstsystems DOT com>, on 10/27/99
   at 01:40 PM, Sterling James <ssjames AT DSTSYSTEMS DOT COM> said:

>Hello,
>I would like some suggest on "How to" move a copy storage pool to a different
>device type. We are currently using a 3490s and would like to use our 3590s.
>I think I could define a DEVCLASS pointing to the 3590s, define the new copy
>stgpool, and do a backup stgpool to the new copy pool. But this would leave the
>old copy storage intact. How would I free up those 3490s.

>Thanks in advance,