> I didn't mean to be smart, sorry if it came out that way. I just wanted to stress that everything you need to perform a DR, including hardcopy reports, utility tapes, DR procedure manual, CD's with software manuals, etc. has to be on a DR site or in the off-site storage, that's all.
Ivica, Well... your post *did* come across as "smart" -- but the **GOOD** form of "smart", adding value to an open subject. There is no need to apologize for adding helpful detail to any subject. There are many new (and future) readers of this list who will benefit from the experiences of those who continue to contribute to the list (some contribute well after they have retired or are forced to leave z/VM). That's what makes this list a true world-wide "z/VM Community" (with the "z/" preface added to eliminate confusion caused by the other late-comer upstart "VM" groups (VMWare, Java VM's, VoiceMail, etc.). I believe that the first use of the term "VM Community" was by Melinda Varian, in her paper "What Mother Never Told You About VM Service, 1983", which while dated by VMSES/E is still a great resource (see: http://www.princeton.edu/~melinda/tutorial.listing ). Your contributions to the list have always been in that welcoming, inclusive spirit. My addition to your post was intended to confirm, and expand upon, what you wrote. My initial response was just to get the ball rolling, expecting that others would continue to contribute from their z/VM D.R. experiences. Thus, those new to z/VM have no reason to experience a disastrous Disaster Recovery, if that's not too redundant. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Ivica Brodaric" <ivica.broda...@gmail.com> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 12/15/2009 06:49 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: VM Best Practices Mike, I didn't mean to be smart, sorry if it came out that way. I just wanted to stress that everything you need to perform a DR, including hardcopy reports, utility tapes, DR procedure manual, CD's with software manuals, etc. has to be on a DR site or in the off-site storage, that's all. Of course, mirroring makes that much easier, because your DR system is just waiting to be IPLed. You have to send less stuff off-site, a lot of it can be kept on disks. Anything that you may need *before* you bring up VM, and that answers questions "where is...?" has to be either in the DR manual or in the hardcopy report on the DR site. My recent experience is also with mirroring - two sites running half of production load each, disk mirroring each way. LPAR configs were identical between sites and DR meant logging on one second level VM on each surviving VM(*) and PROFILE and other EXECs would take care of the rest. But I still miss the good ol' days of walking into a DR site and actually *doing something* to restore the system. Oh, wait, maybe I don't. It's just nostalgia. I was just much younger then. :-) Ivica (*) I don't suggest this setup unless you have plenty of storage and zero paging in production LPARs. At least that. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
