Steve, If I understand correctly your DASD is mirrored to your offsite location. If so the 1-pack recovery system would/could be mirrored there as well. Then there would be no need to keep a DDR tape dump of that volume there. But when preparing for D.R. both belts and suspenders (and offsite clean underwear) is a good idea anyway.
BTW, if you had a test z/VM system which could be IPLed on the bare iron (i.e. the volsers do not begin on cylinder 1, as is often suggested here for 2nd level systems), the test system would suffice to recover just as well as a 1-pack recovery system. We must wear both belts and suspenders here, as we have both. I try to have as many ways out of any hole I might dig as possible - and plenty of clean bandages for the holes I might shoot in my foot. Our 1-pack recovery system was built the Monday following a change made to the SYSTEM CONFIG while preparing for a D.R. test. Due to those SYSTEM CONFIG changes we could not IPL either. A separate z/VM system (already in place for z/OS guests) was used during our D.R. test to DEFINE MDISK and correct the production system SYSTEM CONFIG file. We could just rely on that other system, but as things change, often in a hurry (e.g. systems moving between data centers), I feel more comfortable with a rarely-changed 1-pack recovery system. We place it on an rdev with an easy to remember address (in this case it's 900, but "666" would be even easier if we had that as a DASD address). BTW, we have a D.R. test this weekend. If things go normally, we'll be given the LPAR at about 23:00 Saturday, and be done by about 00:15 -- really only needing about 15 minutes to IPL, but doing a few double-checks anyway. z/VM... gotta love it! :-) If you're reading this and are new to z/VM, take one thing away... build a stable (tested and rarely changed) 1-pack z/VM recovery system. It could save your job one day (or dark night). Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. "Perez, Steve S" <sspe...@corelogic.com> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 02/17/2011 03:04 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: DEVICES stmt in SYSTEM CONFIG Mike, The answer to both those question is 1) yes 2) no. Our DR remote location has 2 LPARs dedicated for our DR Testing. One LPAR is for z/OS and the other for z/VM. I will keep your recovery scenario/suggestion in mind. It looks like something that can be useful in the future when the need arises with the ideal scenario that you posed. Thank you for your insight. Steve From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Mike Walter Sent: Thursday, February 17, 2011 2:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DEVICES stmt in SYSTEM CONFIG Steve, 1) Do you know the volser, and the start and end cylinders of your MAINT CF1 disk? 2) Do you have another z/VM system available (even your D.R. provider's "Floor system")? If the answer to both of those is yes, then you're home free... - Shutdown your partly IPLed z/VM system with the bad config file. >From MAINT on that other z/VM system, CP ATTACH your IPL volume to that system: - CP ATTACH rdev SYSTEM - CP DEFINE MDISK EEE start_cyl end_cyl volser - ACCESS EEE W - XEDIT SYSTEM CONFIG W - fix and FILE the config file - CPSYNTAX SYSTEM CONFIG W - RELEASE W (DET - Bring up your system with the corrected SYSTEM CONFIG file. - Make note of what needs to be fixed when "back home". For you, and anyone else who doesn't have one... When home, - build a 1-pack stand-alone rescue system. Ours is called the "VM Operating System Hipervisor Tool", and resides on a disk with a matching volser: VMOSHT. That volser is easy to remember, easy to find, and pretty self-explanatory. :-) - Test that 1-pack stand-alone rescue system 2nd level (i.e. from your own personal Class G userid, without any special DASD attached. If it needs resources that it doesn't have to come up to the point that MAINT can issue CP DEFINE MDISK, then it's not a stand-alone recovery system. - DDR that volser to tapes, and ensure that a copy is kept onsite, and a copy at your offsite vault. Good Luck! Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. "Perez, Steve S" <sspe...@corelogic.com> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 02/17/2011 02:23 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: DEVICES stmt in SYSTEM CONFIG I do not have another filename to specify. I can create one at a later time after we finish this test because we have a time frame to get this test to work, but in the meantime, is there an override command to the DEVICES OFFLINE_AT_IPL statement in the SYSTEM CONFIG that I can use through the the SALIPL screen ? Thanks, Steve Steve S. Perez zSeries Technical Services From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Schuh, Richard Sent: Thursday, February 17, 2011 2:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DEVICES stmt in SYSTEM CONFIG You specify the filename of the desired CONFIG file in a provided space. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Perez, Steve S Sent: Thursday, February 17, 2011 12:14 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DEVICES stmt in SYSTEM CONFIG What is the command to override that OFFLINE_AT_IPL statement in the SALIPL screen ? Or can we ? Thanks, Steve From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Frank M. Ramaekers Sent: Thursday, February 17, 2011 2:10 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DEVICES stmt in SYSTEM CONFIG You can actually mix them: Devices , Online_at_IPL 0000-FFFF, Offline_at_IPL 000C-000E, Offline_at_IPL 0170-0179, Offline_at_IPL 0500-053F, : : Frank M. Ramaekers Jr. From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Perez, Steve S Sent: Thursday, February 17, 2011 2:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DEVICES stmt in SYSTEM CONFIG Unfortunately we are not at the point where we can issue the VARY online command. The system (Test DR z/VM environment) cannot continue because the OFFLINE_AT_IPL statement contains the address of the PAGE volumes. So we are thinking that having the PAGE volume addresses included in the OFFLINE_AT_IPL list is keeping the PAGE volumes from coming online and therefore preventing the system from initializing. My other option would be to shutdown the DR z/VM environment and update the SYSTEM CONFIG without those ranges and create a new CPLOAD module to see if that is what is actually causing the z/VM system from fully initializing. Thanks, Steve From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Scott Rohling Sent: Thursday, February 17, 2011 1:48 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DEVICES stmt in SYSTEM CONFIG CP VARY ON address ?? Scott Rohling On Thu, Feb 17, 2011 at 12:45 PM, Steve Perez <sspe...@corelogic.com> wrote: Hello Listers, If I have DEVICE addresses in the SYSTEM CONFIG file to be OFFLINE_AT_IPL, is there to dynamically have those devices varied online or override at IPL of a zVM 5.4 ? Thanks, Steve. ****************************************************************************************** This message may contain confidential or proprietary information intended only for the use of the addressee(s) named above or may contain information that is legally privileged. If you are not the intended addressee, or the person responsible for delivering it to the intended addressee, you are hereby notified that reading, disseminating, distributing or copying this message is strictly prohibited. If you have received this message by mistake, please immediately notify us by replying to the message and delete the original message and any copies immediately thereafter. Thank you. ****************************************************************************************** CLLD _____________________________________________________ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com. 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. 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.
