What I am trying to accomplish is changing the COPYPOOL to use the
same DEVICECLASS as the TAPEPOOL. Right now they are using the same tape
drives but different device classes so that the high level qualifiers were
different. On our z/OS system we use CA-1 for tape management. The easiest
and most consistent way to handle tape vaulting and all the associated
reports that go with it, was to use high level qualifiers, (as is the case
with the rest of the products on the mainframe). Doing that rendered TSM
priority handling useless. I know I can now use some additional work keying
on when I am telling TSM what tapes to mark OFFSTE to also tell CA-1 to give
those tapes an OUTCODE and OUTDATE. This will drive the vault handling
properly for CA-1. I never thought I wouldn't be able to migrate to this
new setup in an orderly fashion.
Matt
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 03, 2002 10:41 AM
To: [EMAIL PROTECTED]
Subject: Re: BEST WAY to MIGRATE TO NEW DEVICE CLASS
=> On Mon, 3 Jun 2002 08:21:26 -0400, "MC Matt Cooper (2838)"
<[EMAIL PROTECTED]> said:
> I am in a situation where I want to migrate a COPYPOOL to a different
DEVICE
> CLASS. (I would settle for a change to the high level qualifier on the
tape
> but that can not be done.) I asked TSM and they said that I have to
define
> a new COPYPOOL, associate it with the new DEVICE CLASS and do BACKUP
primary
> pool to COPYPOOL until it has all been copied. I have 10 TB of data in
the
> COPYPOOL and I am running on z/OS. Which means I am usually busy during
1st
> and half of 2nd shift. Either way it would take a week of dedicated tape
to
> tape activity (3 processes at 20GB/hr each) to do.
Well, if you have really reached the conclusion that you need a new
devclass,
you have really limited your options.
Look at it this way: A new devclass is like a new library. If you need to
move all your data from library A to library B, you're going to do a lot of
copying.
major reorganizations of data storage like this just take a long time;
that's
all there is to it.
If what you're doing is (for example) just changing all your 3590Bs to Es,
then you might get away with deleting all the DRIVEs from your old library,
and then re-adding them with the new specifications. In this case, you're
not
generating a new devclass at all. This is a pretty standard step in the
upgrade from a B to an E infrastructure.
If you do this, remember to set all your B volumes to read-only.
- Allen S. Rout
