Re: Disaster Recovery TCPIP Address Issue
Alan is easily distracted... it's almost like someone else was at the keyboard... On 08/12/2010 04:26 PM, Alan Altmark wrote: Pt. Hey, Buddy. Over here. No, over *here*. It' me. Yes, you know who. Wanna know a secret? They (please, no names) are planning to update PUT2PROD in the next release to update production disks by using the technique you describe. I overheard them at the water cooler. Then they started talking about quantum-correlated twin photons and LGR. Whatever that is, it sounds kul. Bye. -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2011 - April 15-19, 2011 Colorado Springs, CO
Re: Disaster Recovery TCPIP Address Issue
Yeah, I know he said DDR, but note that I said "Make the change to that file only". Maybe I should have said "Make the change to that file only rather than using DDR", but I figured that David's a big boy now. Glad to hear that there is to be an expected improvement to PUT2PROD. Jim On 8/12/2010 5:26 PM, Alan Altmark wrote: On Thursday, 08/12/2010 at 05:14 EDT, Jim Bohnsack wrote: Why should changing the SYSTEM NETID on 190 have to be disruptive? Make the change to that file only and do a SAVESYS CMS. To keep things in step, copy the new SYSTEM NETID to 490 with OLDD. Anything that's using SYSTEM NETID will still be seeing the "old" info but that old file relates to the system in use at the moment. He said DDR, which is disruptive to the 190 disk. Error 3 reading file. Alan Altmark z/VM Development IBM Endicott Pt. Hey, Buddy. Over here. No, over *here*. It' me. Yes, you know who. Wanna know a secret? They (please, no names) are planning to update PUT2PROD in the next release to update production disks by using the technique you describe. I overheard them at the water cooler. Then they started talking about quantum-correlated twin photons and LGR. Whatever that is, it sounds kul. Bye. -- James Bohnsack (972) 596-6377 home/office (972) 342-5823 cell
Re: Disaster Recovery TCPIP Address Issue
On Thursday, 08/12/2010 at 05:14 EDT, Jim Bohnsack wrote: > Why should changing the SYSTEM NETID on 190 have to be disruptive? Make > the change to that file only and do a SAVESYS CMS. To keep things in > step, copy the new SYSTEM NETID to 490 with OLDD. Anything that's using > SYSTEM NETID will still be seeing the "old" info but that old file > relates to the system in use at the moment. He said DDR, which is disruptive to the 190 disk. Error 3 reading file. Alan Altmark z/VM Development IBM Endicott Pt. Hey, Buddy. Over here. No, over *here*. It' me. Yes, you know who. Wanna know a secret? They (please, no names) are planning to update PUT2PROD in the next release to update production disks by using the technique you describe. I overheard them at the water cooler. Then they started talking about quantum-correlated twin photons and LGR. Whatever that is, it sounds kul. Bye.
Re: Disaster Recovery TCPIP Address Issue
Why should changing the SYSTEM NETID on 190 have to be disruptive? Make the change to that file only and do a SAVESYS CMS. To keep things in step, copy the new SYSTEM NETID to 490 with OLDD. Anything that's using SYSTEM NETID will still be seeing the "old" info but that old file relates to the system in use at the moment. Jim On 8/12/2010 2:40 PM, David Boyes wrote: Would this be done with the SYSTEM_IDENTIFIER statement in the SYSTEM CON= FIG=20 For the SYSTEM CONFIG changes, yes. for SYSTEM NETID, you need to make the = changes on MAINT 490 and then DDR 490 to 190. Note: disruptive, so do durin= g a maintenance window.=20 and if so, how do I find my current model and cpuid? Looks like the 'q cupid' will give it to me. Yep. Read the notes in the CP Commands manual.=20 Note that multiple CPUIDs can map to the same node id in the case where you= could end up on one of several CECs at the recovery site. = -- James Bohnsack (972) 596-6377 home/office (972) 342-5823 cell
Re: Disaster Recovery TCPIP Address Issue
Hi. To copy 490 to 190, the better option is to use "PUT2PROD CMS". Do it and more... No disruptive, and this update the CMS segment too. Regards, Clóvis |> | From: | |> >--| |David Boyes | >--| |> | To:| |> >--| |IBMVM@LISTSERV.UARK.EDU | >--| |> | Date: | |> >--| |12/08/2010 15:36 | >--| |> | Subject: | |> >----------| |Re: Disaster Recovery TCPIP Address Issue | >--| |> | Sent by: | |> >--| |The IBM z/VM Operating System | >--| > Would this be done with the SYSTEM_IDENTIFIER statement in the SYSTEM CONFIG For the SYSTEM CONFIG changes, yes. for SYSTEM NETID, you need to make the changes on MAINT 490 and then DDR 490 to 190. Note: disruptive, so do during a maintenance window. > and if so, how do I find my current model and cpuid? > Looks like the 'q cupid' will give it to me. Yep. Read the notes in the CP Commands manual. Note that multiple CPUIDs can map to the same node id in the case where you could end up on one of several CECs at the recovery site.
Re: Disaster Recovery TCPIP Address Issue
> Would this be done with the SYSTEM_IDENTIFIER statement in the SYSTEM CONFIG For the SYSTEM CONFIG changes, yes. for SYSTEM NETID, you need to make the changes on MAINT 490 and then DDR 490 to 190. Note: disruptive, so do during a maintenance window. > and if so, how do I find my current model and cpuid? > Looks like the 'q cupid' will give it to me. Yep. Read the notes in the CP Commands manual. Note that multiple CPUIDs can map to the same node id in the case where you could end up on one of several CECs at the recovery site.
Re: Disaster Recovery TCPIP Address Issue
Bobby, For a more expansive review of using the "Record Qualifiers" in "SYSTEM CONFIG", see the post on this listserve at: http://listserv.uark.edu/scripts/wa.exe?A2=ind1002&L=IBMVM&P=R6649&I=-3&X=1C6106111E9F2D0425&Y=Mike.Walter%40hewitt.com (watch out for any URL wrap) For Bobby and EVERYONE ELSE who does not YET know how to search this listserve's archives: -- You might also want to invest a few minutes learning how to search the listserve's archives at: http://listserv.uark.edu/archives/ibmvm.html There's an incredible amount of information available from people who have already trod the path that you're just beginning to go down. Searching the archives can answer immediate questions immediately (instead of overnight), and can also help to keep you from trodding down that path with a self-inflicted gunshot wound. It is very much worth the short time learning to search the archives - especially when you need help in the middle of the night or on a weekend when fewer souls are answering posts here. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Bauer, Bobby (NIH/CIT) [E]" Sent by: "The IBM z/VM Operating System" 08/12/2010 11:10 AM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Disaster Recovery TCPIP Address Issue Would this be done with the SYSTEM_IDENTIFIER statement in the SYSTEM CONFIG and if so, how do I find my current model and cpuid? Looks like the 'q cupid' will give it to me. Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474 -Original Message- From: David Boyes [mailto:dbo...@sinenomine.net] Sent: Thursday, August 12, 2010 11:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Disaster Recovery TCPIP Address Issue >location. While discussing our requirements, the topic of TCPIP addresses >came up. Since the addresses at the offsite location will be different >from our local addresses, we are at a loss as to how to change them. The vendor should be able to give you the CPUIDs of the recovery systems you'll be running on during your test. Add those to SYSTEM NETID and SYSTEM CONFIG with different node names (I use DISASTER). Once that's done, when the system comes up, you can use qualifiers in the TCPIP PROFILE and SYSTEM CONFIG to set up things with the addresses of your disaster recovery system, kinda like this (not precise syntax, so RTFM for it): NORMAL: LINK FOO DISASTER: LINK FOO Presto, no need to change anything actually AT recovery site. 8-) -- db 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 TCPIP Address Issue
All fine ideas that will work for a DR test running with DR test IP addresses (from the DR vendor's LAN?) whilst your real system remains up. If the disaster happens, will your real DR invocation system run with the DR vendor's LAN addresses? If so, how will your live TCPIP clients find your TCPIP servers? VIPA can help with this if you have different policies for DR test and Real DR. Regards, Mike Mike Wawiorko Global z Connectivity and Automation Engineering GISD Core Engineering GRB Technology Barclays Bank -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Bauer, Bobby (NIH/CIT) [E] Sent: 12 August 2010 17:11 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Disaster Recovery TCPIP Address Issue Would this be done with the SYSTEM_IDENTIFIER statement in the SYSTEM CONFIG and if so, how do I find my current model and cpuid? Looks like the 'q cupid' will give it to me. Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474 -Original Message- From: David Boyes [mailto:dbo...@sinenomine.net] Sent: Thursday, August 12, 2010 11:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Disaster Recovery TCPIP Address Issue >location. While discussing our requirements, the topic of TCPIP addresses >came up. Since the addresses at the offsite location will be different >from our local addresses, we are at a loss as to how to change them. The vendor should be able to give you the CPUIDs of the recovery systems you'll be running on during your test. Add those to SYSTEM NETID and SYSTEM CONFIG with different node names (I use DISASTER). Once that's done, when the system comes up, you can use qualifiers in the TCPIP PROFILE and SYSTEM CONFIG to set up things with the addresses of your disaster recovery system, kinda like this (not precise syntax, so RTFM for it): NORMAL: LINK FOO DISASTER: LINK FOO Presto, no need to change anything actually AT recovery site. 8-) -- db This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC.Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised and regulated by the Financial Services Authority.
Re: Disaster Recovery TCPIP Address Issue
My solution for changing TCP/IP IP numbers and other things when doing a disaster recovery is documentated on my VM Download page at: http://zvm.sru.edu/~download Look for PROD_DR HTML and PROD_DR VMARC Basically I ask the OPERATOR at IPL time if we are running PROD or DR and switches are set in VM and VSe to indicate where we are. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 47 years mailto:f...@zvm.sru.edu http://zvm.sru.edu/~fjh +1.724.738.2153 "Yes, Virginia, there is a Slippery Rock" --
Re: Disaster Recovery TCPIP Address Issue
Would this be done with the SYSTEM_IDENTIFIER statement in the SYSTEM CONFIG and if so, how do I find my current model and cpuid? Looks like the 'q cupid' will give it to me. Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474 -Original Message- From: David Boyes [mailto:dbo...@sinenomine.net] Sent: Thursday, August 12, 2010 11:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Disaster Recovery TCPIP Address Issue >location. While discussing our requirements, the topic of TCPIP addresses >came up. Since the addresses at the offsite location will be different >from our local addresses, we are at a loss as to how to change them. The vendor should be able to give you the CPUIDs of the recovery systems you'll be running on during your test. Add those to SYSTEM NETID and SYSTEM CONFIG with different node names (I use DISASTER). Once that's done, when the system comes up, you can use qualifiers in the TCPIP PROFILE and SYSTEM CONFIG to set up things with the addresses of your disaster recovery system, kinda like this (not precise syntax, so RTFM for it): NORMAL: LINK FOO DISASTER: LINK FOO Presto, no need to change anything actually AT recovery site. 8-) -- db
Re: Disaster Recovery TCPIP Address Issue
I use an exit in "node" DTCPARMS that checks the DR status using the CPU serial number, e.g. .*--- .* Add user exit to stack startup .*--- :nick.TCPIP:type.server :class.stack :exit.DRCHECK .*--- .* Add user exit to MPROUTE startup .*--- :nick.MPROUTE :type.server :class.mproute :exit.DRCHECK The exit is specific to our environment, so I won't post it. It calls another EXEC that determines whether we're in DR by checking the CPU serial number. The operator is also prompted at system startup to tell the system whether we're in a DR test or real disaster. DR tests are conducted behind a firewall, so we use different OSA's for test and real DR. For the stack, it copies a DR version of PROFILE TCPIP to TCPIP 191. For MPROUTE, it returns ":Config." with the name of the appropriate MPROUTE CONFIG file. We don't use SYSTEM NETID or SYSTEM CONFIG to change the node name for DR, because we have things that are dependent on the node name. Dennis "If I could not go to heaven but with a [political] party, I would not go there at all." -- Thomas Jefferson -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of McDonough, George Sent: Thursday, August 12, 2010 08:13 To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Disaster Recovery TCPIP Address Issue Hello, Everyone. We are in the planning stages for the first disaster recovery test of our new z/VM environment. This test will be done at an offsite vender location. While discussing our requirements, the topic of TCPIP addresse s came up. Since the addresses at the offsite location will be different from our local addresses, we are at a loss as to how to change them. In our z/OS environment, we just use the vendor's floor system to make our changes. However, in the z/VM restoration we will not have a floor syste m to make similar updates. We believe we're not going to have access to their HMC where we could use the Integrated 3270 Console, but we're still trying to get final confirmation on that. My question is how do other folks get their DR vendor's IP information into and active on the restored VM system? Thanks for your help. George.
Re: Disaster Recovery TCPIP Address Issue
>location. While discussing our requirements, the topic of TCPIP addresses >came up. Since the addresses at the offsite location will be different >from our local addresses, we are at a loss as to how to change them. The vendor should be able to give you the CPUIDs of the recovery systems you'll be running on during your test. Add those to SYSTEM NETID and SYSTEM CONFIG with different node names (I use DISASTER). Once that's done, when the system comes up, you can use qualifiers in the TCPIP PROFILE and SYSTEM CONFIG to set up things with the addresses of your disaster recovery system, kinda like this (not precise syntax, so RTFM for it): NORMAL: LINK FOO DISASTER: LINK FOO Presto, no need to change anything actually AT recovery site. 8-) -- db
Re: Disaster Recovery TCPIP Address Issue
The DR vendor should provide you with some 3270 terminals where you can logon as TCPMAINT (Or whatever user id you use) and then make changes to the TCPIP Profile. Billy On 12 Aug 2010 at 10:13, McDonough, George wrote: > Hello, Everyone. > > We are in the planning stages for the first disaster recovery test of our > new z/VM environment. This test will be done at an offsite vender > location. While discussing our requirements, the topic of TCPIP addresses > came up. Since the addresses at the offsite location will be different > from our local addresses, we are at a loss as to how to change them. In > our z/OS environment, we just use the vendor's floor system to make our > changes. However, in the z/VM restoration we will not have a floor system > to make similar updates. We believe we're not going to have access to > their HMC where we could use the Integrated 3270 Console, but we're still > trying to get final confirmation on that. > > My question is how do other folks get their DR vendor's IP information > into and active on the restored VM system? > > Thanks for your help. > > George. >
Disaster Recovery TCPIP Address Issue
Hello, Everyone. We are in the planning stages for the first disaster recovery test of our new z/VM environment. This test will be done at an offsite vender location. While discussing our requirements, the topic of TCPIP addresse s came up. Since the addresses at the offsite location will be different from our local addresses, we are at a loss as to how to change them. In our z/OS environment, we just use the vendor's floor system to make our changes. However, in the z/VM restoration we will not have a floor syste m to make similar updates. We believe we're not going to have access to their HMC where we could use the Integrated 3270 Console, but we're still trying to get final confirmation on that. My question is how do other folks get their DR vendor's IP information into and active on the restored VM system? Thanks for your help. George.
