As we have 9 different VM systems with varying degrees of criticality - here is what we do :-
1. We have a 2nd level 6 pack build system. Disks are 3338 cyl minidisks (starting at real cyl 1) with the distribution labels. A new set for each VM release. 2. If we are about to do a major maintenance, we shut down the build system and back it up (physically) 3. We apply all maintenance to the build system and do the PUT2PROD here as well. We have 2 other vendor products that have to be built with CP that are applied here. 4. When we are happy with our build system then we migrate the updated levels to our production systems component at a time. To help with this we have an ISLINK between our build system and the production network. 5. First we do CP by putting the new CPLOAD module on the CF1 disks and doing a safe rename so we can easily fall back to the previous. 6. Next we migrate CMS by copying the build system CMS disks to alternate CMS disks on production, switching the addresses and loading the new NSS 7. After that we migrate each of the other components by migrating the minidisks to alternate addresses and switching them. Clearly, while that is the principal, there is a lot more detail than I can include in a forum append. The big advantage to us is that it is easy to progressively implement and test. Naturally, fallback is very quick and simple. I am not saying this is best practice or for everyone - but it is a quick, simple and safe procedure for our environment. Colin Allinson VM Systems Support Amadeus Data Processing GmbH
