Rebecca, <snip> >One question I haven't found the answer to: Is there anything special I have >to worry about with the DB2 storage groups and/or classes. I know DB2 has a >thing where it defines one or the other (not sure which) but is there any >connection between the DB2 definition/setting and the SMS configuration? >Will the DBA's need to make changes to reflect the changes in the SMS >configuration?
Assuming you are not using Object Access Method (OAM), you should only have to change the storage class you are assigning to the DB2 dataset to the new/surviving storage class. >My plan for merging storage groups is to: 0. Make copy of current SMS SCDS. You most likely have a backup but it would be helpful to have a copy to use as a reference as you make changes. >1. Modify the ACS STORGRP routine so that everything assigned to a storage >group being merged is changed to be assigned to the target storage group. >Instead of creating new storage groups, I am keeping some of the old ones >and merging into them. As John Ticic pointed out, make sure the merged storage classes have the same/similar attributes. No problem with having more than one surviving storage class. >2. Delete all volumes from a storage group being merged and added them to >the target storage group. You will need to do step 3 first since you can only have a given volser once. You just need to be sure you include all volumes in the deleted group(s) in the successor group. Since you are including all volumes into the successor storage group, there should be no need to move any datasets. If the dataset has the right placement now, it will have the right placement in the new SMS configuration. >3. Delete the now empty storage groups. 3a. Look at using Naviquest to build test cases and test your current and proposed configuration against them. You should be able to verify everything before you do step 4. >4. Activate the new configuration (when doing this for the production and >development pools, it will be done on a Sunday when they are down just to >ease the worries of management - plus it is easy for us to get maintenance >windows on Sundays.) >For storage classes: >1. Modify the ACS STORCLAS routine so that everything assigned to a storage >class being merged is directed to the target storage class. Naviquest again would be your friend here. >2. Will not actually delete the merging storage classes from the SMS >configuration or the STORGRP routine. >3. Eventually move datasets that don't get redefined with the new storage >class. IDCAMS alter command can be used to change the storage class. You can use dcollect and scan the output looking for storage classes you want to change. No need to move/reallocate a dataset. >4. Once there are no longer datasets associated with the old storage classes, >delete them from both the configuration and the ACS STORGRP routine. Good plan. I would do both storage class and storage group at the same time but I have plenty of experience (and the scars to prove it). Regards, John ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
