I found it more easy to keep a backup copy of the runtime "object": - CP: CPLOAD MODULE and CPOLD MODULE on MAINT CF1 alternatively, use MAINT CF2 as fallback of CF1 - CMS: MAINT 190 and 490; 193 and 493 - TCPIP: TCPMAINT 59x and 159x - etc If you have a copy of the entire resident, when you switch, you switch also all other minidisks that are located on the resident, for example: if OPERATOR 191 would be there, switching gives does not only backout CP/CMS by gives you the old copy of OPERATOR 191, with maybe backlevel automation execs, and -if using PROP- the outdated console logs. And I didn't mention the spool yet: warm & checkpoint areas are by default located on 540RES, they describe the spool packs, the checkpoint area on the copied 540RES would surely not match with what is on the spool packs, so this "hot standby" also requires you'd copy the spool pack(s). Therefore one other alternative is to have a "good", mini, VM system that you can IPL and that would allow to repair the broken VM system. Everything would fit on one pack if you just copy what you need, some SPOOL, a MAINT CF1, a MAINT 191/190/19E/193/19D, TCPMAINT and a directory would suffice. The label of that one pack VM system should be different from your production disks, this way you will be able to "mount" every minidisk of the production system in the mini VM. But as mentioned earlier, I didn't feel the need to have such a system.
2009/6/24 Le Grande Valerie <valerie.legra...@sentry.com> > I am looking for some input: > > How do you do maintenance and keep a "hot standby" volume (and old 540RES > and newly maintained 540RES)? > We have to bring maintenance in "off hours" and like to have a volume > operators can switch back to should there be problems. > > If anyone can share how-to, please contact me off list (or copy me on the > list entry - I can't get to the list from my current work location). > > Valerie Le Grande > valerie.legra...@sentry.com > -- Kris Buelens, IBM Belgium, VM customer support
