MVSFORUMS.com

[djf]

We are moving to a new SAN, 3390's only.

I have a storage pool on 80's but have added into the pool some 90's.

When the new SAN is installed, we will do full volume copies 90's to 90's which is the easiest way.

I need to allocate 300+ datasets on the 90's but SMS just LUVS to get involved and putting some on the 80's. because the datasets are DA format (3rd party) I am allocating them with the TSO ALLOC DS('ABC.XYZ.COPY') LIKE('ABC.XYZ') UNIT(3390) VOL(NEWVOL)

So is there any way to quiesce the 80's so that he WILL put them on the 90's?

[warp5]

Very simple, go into ISMF, enter the storage group processing, enter the storage group in question and use the volumes processing, use the alter volumes processing to set the volumes to quiesce or quinew (only used for new datasets if the system does not have enough room on other disks that are enabled). Don't forget to activate the SMS afterwards.

[djf]

Thanks!

I admit I got desperate and inactivated the volumes then reactivated them after the datasets were created.

[djf]

I have another question for anyone who knows.

There is one particular 3380 that might give me problems... it is a volume that has about ten catalogs on it. (but not the master)

When the system was originally set up, they defined an SMS volume with storage group name PRIMARY and had the ACS routines put anything that started with CAT or CATALOG on that volume.

A few years ago I got somewhat fed up with that, as I like the catalogs that control things to be on or near the volumes they generally manage (for instance the DB2 catalogs, one for the DB2 system stuff and another for the DB2 data, are on the DB2 distribution volumes).

Anywaze I need to move these catalogs living on this 80 to a 90 that either is or is not under SMS, I can do it either way, I just have to do something that is guaranteed to work.

Ideas?
Suggestions?
TIA.
djf

[Bill Dennis]

Get rid of the generic check for 'CAT' or 'CATALOG' so the non-SMS catalogs can be allocated where you want them.

For the ones that will reside on SMS-controlled volumes, change the ACS routines to have an entry for each assigning the correct pool (Ex. 'CATALOG.PROD.DB2' ) . Be sure it will allow for the CATINDEX, too.
_________________
Regards,
Bill Dennis

Disclaimer: My comments on this foorum are my own and do not represent the opinions or suggestions of any other person or business entity.

[djf]

Done that. But how do I move them?

[warp5]

You can do it step by step, for example one HLQ after another. Here is an example:

[Bill Dennis]

warp's method will move entries to a different catalog.

Our IDCAMS process to move an entire catalog:

1. EXPORT TEMPORARY two times (in case one can't be read later)
2. ALTER LOCK the catalog to prevent new activity
3. DELETE RECOVERY (delete UCAT but retain ALIAS entries in MCAT)
4. DEFINE the catalog on a new volume
5. IMPORT INTOEMPTY from the REPRO file above
6. ALTER UNLOCK

For more details and sample JCL, see the DFSMS Managing Catalogs manual section on Moving Catalogs.
_________________
Regards,
Bill Dennis

Disclaimer: My comments on this foorum are my own and do not represent the opinions or suggestions of any other person or business entity.

[djf]

Thank you guys both very much. I admit I was about to post and say the first method wouldn't seem to work for me because I have about a dozen catalogs and hundreds, if not thousands, of aliases.

The second method is much more along the lines of what I need. I can do some non-destructive testing and make it foolproof.

Of course an old friend of mine said you can never make anything foolproof, because fools are such geniuses!

Regards,
djf

[djf]

[expat]

Bills method of moving catalogs is probably the best one.

For allocating datasets on specificvolumes in a pool, don't forget to use a STORCLAS with the Guaranteed Space attribute.
_________________
If it's true that we are here to help others,
then what exactly are the others here for ?