Right. Not a problem using DEDICATE nn VOLID VOLSER. We also have hipersockets and OSA devices defined with DEDICATE statements.....
That's where the big question comes into play. How do we handle these. Marcy Cortes <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 03/10/2008 01:50 PM Please respond to The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Disaster Recovery question Ooo, wait. You said Linux devices are DEDICATE. Does that mean DASD too? Do you have duplicate VOLSERS on your system? If not, you can probably change the DEDICATEs to MDISK 000 END and be OK, or if you'd like DEDICATE nnn VOLID VOLXXX ... That'll get you around that use of real addresses. Marcy Cortes "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Cortes, Marcy D. Sent: Monday, March 10, 2008 10:43 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Not necessarily. All you really need is SYSTEM NETID based on the CPU of the hotsite that triggers TCPIP to use different config files. We run different OSA addresses and routing configs in our hotsite env (in house, but same concept). (Don't use ATTACH and DEDICATE - have your attach instructs in TCPIPs dtcparm files and you won't have anything to update when you get there :) Marcy Cortes "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Frazier Sent: Monday, March 10, 2008 10:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Unless the hotsite is willing to reconfigure their machine to match your addresses you must run second level. I have never known of a hotsite that will do that. Define a guest on their VM with all the right addresses. Bring your system up second level on that guest. Karl Kingston wrote: > > We are in the process of planning our first disaster recovery of our > z/VM system. > > We have access to an LPAR at our DR hotsite. > > 1) how do I account for differences in OSA addresses, Hipersocket > addresses, and DASD addresses? The only DASD ww have that are VM only > us the 530RES, 530SPL and 3 page volumes. All other devices are for > z/Linux and are dedicated by directory entries. > > My take was to bring up z/VM 2nd level on the hotsite's floor system and > run with that. But they are not recommending it. > > What can I do to avoid making config changes because of DR? > > Thanks! > -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
