Re: Recovery question
Hi Thanks, I did not bring the new DIRECTORY online I thought about this but I did not know the exact procedure to accomplish under the working system. I guess I also thought that at IPL time it would bring in the USER DIRECTORY that was sitting at 511 175(in my case). I understand now how this is working. Thanks again for the help it is much appreciated. I am LEARNING!! Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Thursday, October 02, 2008 10:10 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Recovery question I don't see any mistakes. However - For SYSTEM CONFIG: are you sure that DEFINE MDISK 991 39 120 53DRES points to the CF1 of the new system, and/or that the new system is IPLed with CF1 as its IPL "input"? - For the CP directory You did mention you changed the directory source, but not that you placed the changed directory online on the RES of the new system, So DEFINE MDISK 991 511 175 53DRES #ACC 991 M DETACH 123 DEFINE MDISK 123 0 END 53DRES DIRECTXA fn DIRECT M DET 123 991 2008/10/2 Martin, Terry R. (CMS/CTR) (CTR) <[EMAIL PROTECTED]> > > Hi > > > > I am trying to bring up my test LPAR which is a clone of another VM LPAR. Before I did this I needed to update the SYSTEM CONFIG file and the USER DIRECTORY to point to different RES, PAGE, SPOOL..etc. > > > > I attached the RES of the system I am trying to bring up to the working system, I then issued a DEFINE MDISK 991 39 120 53DRES and then ACC 991 M. > > > > After I did this I was pointing to my SYSTEM CONFIG file on the TEST RES. I made the changes to the SYSTEM CONFIG file and saved it. > > > > Next, I wanted to change the USER DIRECT to point to different RES and such. I did another DEFINE MDISK 991 511 175 53DRES and then ACC 991 M. > > > > After I did this I was pointing to my USER DIRECT file on the TEST RES. I made the changes to the USER DIRECT file and saved it. > > > > Next, I tried IPLing the TEST LPAR and I noticed that it was still looking at the SYSTEM CONFIG without my changes from above as well the USER DIRECT without my changes from above. It appears that the changes did not take. > > > > Where did I go wrong? > > > > Thank You, > > > > Terry Martin > > Lockheed Martin - Information Technology > > z/OS & z/VM Systems - Performance and Tuning > > Cell - 443 632-4191 > > Work - 410 786-0386 > > [EMAIL PROTECTED] > > -- Kris Buelens, IBM Belgium, VM customer support
Re: Recovery question
First another question. When you updated the USER DIRECT did you expect the changes made there to b online when you IPL's the system? You did not mention a DIRECTXA of the USER DIRECT to the new RES pack (assuming that is where the DRCT space is allocated). Without those changes you may not be seeing any of the changes you expect to see. The USER DIRECT file is just a source file. The DRCT space allocated for the system is where CP reads all the definitions. Bob Bates Enterprise Hosting Services - Enterprise Virtualization - z/VM and z/Linux <http://ehs.homestead.wellsfargo.com/Mainframe/zSS/zSE/zVM-zLinux/Pages/ default.aspx> w. (469)892-6660 c. (214) 907-5071 "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." _ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Thursday, October 02, 2008 8:42 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Recovery question Hi I am trying to bring up my test LPAR which is a clone of another VM LPAR. Before I did this I needed to update the SYSTEM CONFIG file and the USER DIRECTORY to point to different RES, PAGE, SPOOL..etc. I attached the RES of the system I am trying to bring up to the working system, I then issued a DEFINE MDISK 991 39 120 53DRES and then ACC 991 M. After I did this I was pointing to my SYSTEM CONFIG file on the TEST RES. I made the changes to the SYSTEM CONFIG file and saved it. Next, I wanted to change the USER DIRECT to point to different RES and such. I did another DEFINE MDISK 991 511 175 53DRES and then ACC 991 M. After I did this I was pointing to my USER DIRECT file on the TEST RES. I made the changes to the USER DIRECT file and saved it. Next, I tried IPLing the TEST LPAR and I noticed that it was still looking at the SYSTEM CONFIG without my changes from above as well the USER DIRECT without my changes from above. It appears that the changes did not take. Where did I go wrong? Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED]
Re: Recovery question
I don't see any mistakes. However - For SYSTEM CONFIG: are you sure that DEFINE MDISK 991 39 120 53DRES points to the CF1 of the new system, and/or that the new system is IPLed with CF1 as its IPL "input"? - For the CP directory You did mention you changed the directory source, but not that you placed the changed directory online on the RES of the new system, So DEFINE MDISK 991 511 175 53DRES #ACC 991 M DETACH 123 DEFINE MDISK 123 0 END 53DRES DIRECTXA fn DIRECT M DET 123 991 2008/10/2 Martin, Terry R. (CMS/CTR) (CTR) <[EMAIL PROTECTED]> > > Hi > > > > I am trying to bring up my test LPAR which is a clone of another VM LPAR. > Before I did this I needed to update the SYSTEM CONFIG file and the USER > DIRECTORY to point to different RES, PAGE, SPOOL..etc. > > > > I attached the RES of the system I am trying to bring up to the working > system, I then issued a DEFINE MDISK 991 39 120 53DRES and then ACC 991 M. > > > > After I did this I was pointing to my SYSTEM CONFIG file on the TEST RES. I > made the changes to the SYSTEM CONFIG file and saved it. > > > > Next, I wanted to change the USER DIRECT to point to different RES and such. > I did another DEFINE MDISK 991 511 175 53DRES and then ACC 991 M. > > > > After I did this I was pointing to my USER DIRECT file on the TEST RES. I > made the changes to the USER DIRECT file and saved it. > > > > Next, I tried IPLing the TEST LPAR and I noticed that it was still looking at > the SYSTEM CONFIG without my changes from above as well the USER DIRECT > without my changes from above. It appears that the changes did not take. > > > > Where did I go wrong? > > > > Thank You, > > > > Terry Martin > > Lockheed Martin - Information Technology > > z/OS & z/VM Systems - Performance and Tuning > > Cell - 443 632-4191 > > Work - 410 786-0386 > > [EMAIL PROTECTED] > > -- Kris Buelens, IBM Belgium, VM customer support
Recovery question
Hi I am trying to bring up my test LPAR which is a clone of another VM LPAR. Before I did this I needed to update the SYSTEM CONFIG file and the USER DIRECTORY to point to different RES, PAGE, SPOOL..etc. I attached the RES of the system I am trying to bring up to the working system, I then issued a DEFINE MDISK 991 39 120 53DRES and then ACC 991 M. After I did this I was pointing to my SYSTEM CONFIG file on the TEST RES. I made the changes to the SYSTEM CONFIG file and saved it. Next, I wanted to change the USER DIRECT to point to different RES and such. I did another DEFINE MDISK 991 511 175 53DRES and then ACC 991 M. After I did this I was pointing to my USER DIRECT file on the TEST RES. I made the changes to the USER DIRECT file and saved it. Next, I tried IPLing the TEST LPAR and I noticed that it was still looking at the SYSTEM CONFIG without my changes from above as well the USER DIRECT without my changes from above. It appears that the changes did not take. Where did I go wrong? Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED]
Re: Disaster Recovery question
We have 1 VM and 20 MVS. At DR site we have a IBM VM used to restore our VM hypervisor. The VM volumes for the hypervisor are the same DASD we used into prod. We say that all the cpowned dasd are absolutely required for our DR VM. (Us, we use Hidro to restore, so the catalog is on a cpowned dasd). We omit TDIS K and PAGE from the backup. They are formated at DR site. The VM in prod sees all the DASD volumes. Before each DDR backup, we exec ute a rexx pipe to create a map of all the rdev with the corresponding volser . The rexx updates all the VM & MVS directories. VMIMAGE contains all t he MDISK, all the directories have a link to this userid. At DR site, just after restoring our VM, we IPL it at 1st level. We reexecute our rexx tool which is used to query all the dasd available an d do the fastidious work to map DASD volumes at model level : input is 3380 -3, output is 3380-3 not something else. Then the dasd is labeled. When all this work is done, we execute the restore. We do the mapping address this manner. Because everything was labeled as it was when we were in prod, we never meet a problem when we restore. - We always do our DR on the same site, VTAM and TCPIP configs are hardcoded. The proper config is applied to them by testing the cpuid. - We use vtctc to communicate between the mvs. We used this method for 5 years twice per year. Alain Benveniste Paris, France
Re: Disaster Recovery question
On Tuesday, 03/11/2008 at 10:41 EDT, Lee Stewart <[EMAIL PROTECTED]> wrote: > In addition to all the good advice already, I will add: Do not try to > run your VM system 2nd level if you have Linux guests. Performance of > the Linux guests will be terrible. There are only two levels of > hardware virtualization. That leaves your Linux guests being > virtualized in software simulation -- which is way slow... The Interpretive Execution Facility (SIE) is not really simulated so much as there is a "pancake effect" as the description of the nth level virtual machine is transformed by each layer of CP into a successively smaller SIE descriptor. E.g. 50% of the 3rd-level guest pages appear to be resident, as far as the 2nd-level CP is concerned. But not really. Only half of the 2nd level CP's pages are, in fact, resident. Maybe that means only 25% of the 3rd level guest pages are really resident. Add to that, the 3rd level guest is getting a slice of a slice of the CPU. And, finally, I/O is going through multiple address translations. So if you want to use z/VM only as a thin "RDEV translator" you need to very specifically size and configure the 1st-level system to do that. This could mean each hosting z/VM LPAR has only a single second-level z/VM, with locked pages, dedicated XSTORE, dedicated CPUs, elongated time slices, and so on. These kinds of thing don't eliminate the "pancake effect", of course, but they can help minimize shrinkage (ahem) of the virtual machine as it glides towards the hardware. Alan Altmark z/VM Development IBM Endicott
Re: Disaster Recovery question
VM is volume id based. (Many years ago, it was not). That being said, VM, when it is IPL'ed, will go and look at all of the dasd that it can touch and find out, among other things, what the volid is. Only if it can't find a volid will inform you. It's up to you how to handle that situation. The DR site will most likely give you the real address of the OSA cards. Depending on how you have yours defined, i.e, DEDICATE statement, etc. you just change the real address on the statement to point to their real address. You leave the virtual address, the address that you apps know it as, alone. To echo your DR site provider recommendations, you do not want to run VM 2nd level in a production or DR situation. Yes, it will run, but not as well as natively. We restore our base system,(about 12 tapes) 2nd level, then IPL that 1st level and start restoring everything else. Steve G. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Karl Kingston Sent: Monday, March 10, 2008 1:21 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Disaster Recovery question 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!
Re: Disaster Recovery question
In addition to all the good advice already, I will add: Do not try to run your VM system 2nd level if you have Linux guests. Performance of the Linux guests will be terrible. There are only two levels of hardware virtualization. That leaves your Linux guests being virtualized in software simulation -- which is way slow... Either run your VM in their LPAR, or if you have a small number of guests, just run your Linux machines in their VM. Most DR vendors "should" know better than recommending VM under VM if you have Linux guests, but Lee 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! -- Lee Stewart, Senior SE Sirius Computer Solutions Phone: (303) 798-2954 Fax: (720) 228-2321 Email: [EMAIL PROTECTED] Web: www.siriuscom.com
Re: Disaster Recovery question
cmdline
etxt.0=4
'PIPE STEM etxt. | CONS'
Call Exit 20
NoValue:
etxt.1='+++ "NoValue:" error rtn entered in:' ,
rexxback('*','OWNER')', rc='rc
etxt.2='+++ from line:' sigl', which reads:'
etxt.3='+++'sourceline(sigl)
etxt.4='+++ which translates to:' value(strip(sourceline(sigl),'B'))
etxt.5='+++ Variable with no value is:' condition('Description')
etxt.0=5
'PIPE STEM etxt. | CONS'
Call Exit 24
/* Epilog ***
* Function - TCPIP svm startup exit. *
* Component of - TCPIP at Some Company*
* Command format- n/a *
* Called by - "TCPIP DTCPARMS" file on TCPMAINT 198 disk. *
* Program Lang. - CMS REXX *
* Date Written - 20010626 *
* Author- Anon E. Mouse*
* Changed | By | Description of Change*
* +-+- *
* mmdd iii - Added attaching D.R. OSA's at prod addresses *
* *
/
The same code:
parse value diag(08,'QUERY USERID') with . . ConfigSysId . '15'x .
/* The above is the SYSTEM CONFIG value */
?home=(ConfigSysId='MYHOMEID')/* <--- Change to your nodename */
?recover=(ConfigSysId='RECOVERY') /* We use this for on-site D.R. */
?disaster=(ConfigSysId='DISASTER') /* This for off-site D.R. */
can be used by various service machines (maybe AUTOLOG1?) to decide
what should be done automatically based on where they are being started.
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
"Karl Kingston" <[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System"
03/10/2008 12:20 PM
Please respond to
"The IBM z/VM Operating System"
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Disaster Recovery question
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!
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.
Re: Disaster Recovery question
We do ours via NAT translation in the router. The network people make it transparent to the OS be it z/VM or z/OS. On the systems we maintain the same IP addresses as production. Then when we go to the DR site (which is an internal site) we translate 10.9 to 10.25. Then no need to change anything on the local systems in DR mode. Andy Internet: Mailto:[EMAIL PROTECTED] > > 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! The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
Re: Disaster Recovery question
For the TCPIP machines, it's not too difficult. You have an alternate machine or config files and in the dtcparms something like :nick.TCPIPDR :type.server :class.stack :attach.3000-3002 And you can bring up that service machine instead. Or change the system netids to make it something like DRSYS and instead of picking up say PROFILE TCPIP it will pick up DRSYS TCPIP with appropriate DRSYS DTCPARMs. Marcy Cortes Team Lead, <http://ehs.homestead.wellsfargo.com/Mainframe/zSS/zSE/zVM-zLinux/Pages/defa ult.aspx> Enterprise Virtualization - z/VM and z/Linux Enterprise Hosting Services w. (415) 243-6343 c. (415) 517-0895 "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." _ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Karl Kingston Sent: Monday, March 10, 2008 10:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question 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 03/10/2008 01:50 PM Please respond to The IBM z/VM Operating System 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
Re: Disaster Recovery question
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 03/10/2008 01:50 PM Please respond to The IBM z/VM Operating System 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
Re: Disaster Recovery question
On Monday, 03/10/2008 at 01:52 EDT, "Schuh, Richard" <[EMAIL PROTECTED]>
wrote:
> You could use the volume serial in any DEDICATE statements in place of
> the real address ("DEDICATE vdev volid" or "DEDICATE vdev VOLID volid").
> That could save you from having to make that kind of directory change.
Cool. I did not know that. But for OSAs and FCPs, you still need to do
the reconfig. Using a VSWITCH instead of dedicating OSAs reduces the
effort even further.
Alan Altmark
z/VM Development
IBM Endicott
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
Re: Disaster Recovery question
You could use the volume serial in any DEDICATE statements in place of
the real address ("DEDICATE vdev volid" or "DEDICATE vdev VOLID volid").
That could save you from having to make that kind of directory change.
Regards,
Richard Schuh
> -Original Message-
> From: The IBM z/VM Operating System
> [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark
> Sent: Monday, March 10, 2008 10:40 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Disaster Recovery question
snip
>
> Your ATTACHes or DEDICATEs have a virtual address and a real
> address. You will need to update the real addresses to match
> your DR config. Leave the virtual addresses alone.
> Remember, ATTACH and DEDICATE have significantly different syntax:
> ATTACH rdev vdev
> DEDICATE vdev rdev
>
> Alan Altmark
> z/VM Development
> IBM Endicott
>
Re: 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
Re: Disaster Recovery question
On Monday, 03/10/2008 at 01:23 EDT, Karl Kingston <[EMAIL PROTECTED]> 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? If you're going to come up 1st level, you will HAVE to make config changes. Your ATTACHes or DEDICATEs have a virtual address and a real address. You will need to update the real addresses to match your DR config. Leave the virtual addresses alone. Remember, ATTACH and DEDICATE have significantly different syntax: ATTACH rdev vdev DEDICATE vdev rdev Alan Altmark z/VM Development IBM Endicott
Re: 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
Disaster Recovery question
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!
