Re: DR Sysplex Procedure
It's very hard to give advice on DR network issues because so much depends on configuration. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Elaine Beal Sent: Monday, February 3, 2020 12:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: DR Sysplex Procedure CAUTION EXTERNAL EMAIL Thanks all. We were able to issue the start policy for the DR policy and all went well! till we got to the network :) Elaine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DR Sysplex Procedure
Thanks all. We were able to issue the start policy for the DR policy and all went well! till we got to the network :) Elaine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DR Sysplex Procedure
Thank you. I believe you may have hit on our issue. We're getting the in use for the LOGR which is not new and I am okay with that. I'm confident we're picking up the DR COUPLExx but we've never had the POLICY statement. We were planning on issuing the SETXCF START with the new policy name. The last test we had an authorization issue on the SETXCF from the alternate console which we were using for DR. I tried to enter it from the HMC console but strangely, it would not take the whole command, cut it off at some point. Maybe because we weren't far enough along in the IPL but I was able to vary it as a console. I like the idea of using POLICY instead of SETXCF. At least no authorization issues:) Another test this weekend... I'll keep you posted! Elaine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DR Sysplex Procedure
These recommendations are culled from the procedure we've used for 20 years. -- With a new (empty) CFRM data set, you should not see any reference to the production policy. -- 'IN USE BY ANOTHER SYSPLEX' suggests that you are pointing to (a copy of) the prod version, not the DR version. -- You need to name the new CFRM couple data set in your DR PARMLIB, e.g. member COUPLEDR. That same member must also name your DR policy because there will be no active policy on the first IPL: CFRMPOL(drpolicy) /* CFRM POLICY TO ACTIVATE IF NONE FOUND */ -- When we IPL first time in DR with a new CFRM couple data set but a copy of prod sysplex couple, we are prompted to use the prod guy last used (no) or the new guy named in PARMLIB (yes). You can send me notes directly to clarify these or other points. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Elaine Beal Sent: Thursday, January 23, 2020 11:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: DR Sysplex Procedure To expand on this... yes, we are just getting to the DR test:) I have new XCF and CFRM datasets pointing to new plant id and serial number, policy but no new LOGR and WLM, using same as prod (on another machine) defined a new policy in DR CFRM We IPLd at the other site for DR and got the following- IXC248E COUPLE DATA SET dsname ON VOLSER volser FOR typename MAY BE IN USE BY ANOTHER SYSPLEX. IXC247D REPLY U to ACCEPT USE OR D TO DENY USE OF THE COUPLE DATA SET FOR typename. to which both are replied to with U ISG379E GRS UNABLE TO CONNECT TO THE ISGLOCK STRUCTURE. VALIDATE THAT THERE IS A COUPLING FACILITY DEFINED IN THE CFRM POLICY AND THAT IT IS PHYSICALLY CONNECTED TO THE SYSTEM. ENSURE THAT THE CF IS IN THE PREFLIST FOR THE ISGLOCK STRUCTURE. CF facility is same as prod and is defined in DR CFRM CF is in PREFLIST one unusual thing is on my report for the DR CFRM it shows both the prod policy and the new DR policy but not sure why since I formatted a new CFRM The backup CTCs are in parmlib but could possibly not be connected. should I remove those? Thanks, Elaine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DR Sysplex Procedure
Unless we're picking up the wrong COUPLE member, the CFRM and XCF are pointing to the DR datasets -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DR Sysplex Procedure
We have defined in our policy both the CF's normally in use during Production and the CF that will be used in a DR. That way when the policy is replicated to the DR site all the information required is already present and we do not have to switch policies. In normal life a D CF command shows one unreachable CF and 2 active ones. During DR the opposite shows with the DR CF active and the 2 normal ones unreachable. Jerry Whitteridge Delivery Manager / Mainframe Architect GTS - Safeway Account 602 527 4871 Mobile jerry.whitteri...@ibm.com IBM Services IBM Mainframe Discussion List wrote on 01/23/2020 12:39:56 PM: > From: Elaine Beal > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 01/23/2020 12:40 PM > Subject: [EXTERNAL] Re: DR Sysplex Procedure > Sent by: IBM Mainframe Discussion List > > To expand on this... > yes, we are just getting to the DR test:) > > I have new XCF and CFRM datasets pointing to new plant id and serial > number, policy > but no new LOGR and WLM, using same as prod (on another machine) > > defined a new policy in DR CFRM > > We IPLd at the other site for DR and got the following- > > IXC248E COUPLE DATA SET dsname ON VOLSER volser FOR typename MAY > BE IN USE BY ANOTHER SYSPLEX. > > IXC247D REPLY U to ACCEPT USE OR D TO DENY USE OF THE COUPLE DATA > SET FOR typename. > > to which both are replied to with U > > ISG379E GRS UNABLE TO CONNECT TO THE ISGLOCK STRUCTURE. VALIDATE > THAT THERE IS A COUPLING FACILITY DEFINED IN THE CFRM POLICY AND > THAT IT IS PHYSICALLY CONNECTED TO THE SYSTEM. ENSURE THAT THE CF IS > IN THE PREFLIST FOR THE ISGLOCK STRUCTURE. > > CF facility is same as prod and is defined in DR CFRM > CF is in PREFLIST > > one unusual thing is on my report for the DR CFRM > it shows both the prod policy and the new DR policy but not sure why > since I formatted a new CFRM > > The backup CTCs are in parmlib but could possibly not be connected. > should I remove those? > > Thanks, > Elaine > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DR Sysplex Procedure
It sounds like your COUPLExx still points to your prod XCF and CFRM datasets. On Thu, Jan 23, 2020 at 1:40 PM Elaine Beal wrote: > To expand on this... > yes, we are just getting to the DR test:) > > I have new XCF and CFRM datasets pointing to new plant id and serial > number, policy > but no new LOGR and WLM, using same as prod (on another machine) > > defined a new policy in DR CFRM > > We IPLd at the other site for DR and got the following- > > IXC248E COUPLE DATA SET dsname ON VOLSER volser FOR typename MAY BE IN > USE BY ANOTHER SYSPLEX. > > IXC247D REPLY U to ACCEPT USE OR D TO DENY USE OF THE COUPLE DATA SET > FOR typename. > > to which both are replied to with U > > ISG379E GRS UNABLE TO CONNECT TO THE ISGLOCK STRUCTURE. VALIDATE THAT > THERE IS A COUPLING FACILITY DEFINED IN THE CFRM POLICY AND THAT IT IS > PHYSICALLY CONNECTED TO THE SYSTEM. ENSURE THAT THE CF IS IN THE PREFLIST > FOR THE ISGLOCK STRUCTURE. > > CF facility is same as prod and is defined in DR CFRM > CF is in PREFLIST > > one unusual thing is on my report for the DR CFRM > it shows both the prod policy and the new DR policy but not sure why since > I formatted a new CFRM > > The backup CTCs are in parmlib but could possibly not be connected. should > I remove those? > > Thanks, > Elaine > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DR Sysplex Procedure
To expand on this... yes, we are just getting to the DR test:) I have new XCF and CFRM datasets pointing to new plant id and serial number, policy but no new LOGR and WLM, using same as prod (on another machine) defined a new policy in DR CFRM We IPLd at the other site for DR and got the following- IXC248E COUPLE DATA SET dsname ON VOLSER volser FOR typename MAY BE IN USE BY ANOTHER SYSPLEX. IXC247D REPLY U to ACCEPT USE OR D TO DENY USE OF THE COUPLE DATA SET FOR typename. to which both are replied to with U ISG379E GRS UNABLE TO CONNECT TO THE ISGLOCK STRUCTURE. VALIDATE THAT THERE IS A COUPLING FACILITY DEFINED IN THE CFRM POLICY AND THAT IT IS PHYSICALLY CONNECTED TO THE SYSTEM. ENSURE THAT THE CF IS IN THE PREFLIST FOR THE ISGLOCK STRUCTURE. CF facility is same as prod and is defined in DR CFRM CF is in PREFLIST one unusual thing is on my report for the DR CFRM it shows both the prod policy and the new DR policy but not sure why since I formatted a new CFRM The backup CTCs are in parmlib but could possibly not be connected. should I remove those? Thanks, Elaine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DR Sysplex Procedure
At one point, I had a setup that included a SITE system symbol in the CDSs for XCF and CFRM to auto-resolve such things Rob Schramm Senior Systems Consultant On Thu, Oct 17, 2019 at 12:41 PM Elaine Beal wrote: > Yes, I would IPL with a different loadparm to point to COUPLExx with DR > XCF and CFRM > but WLM and LOGR would not change (use same ones as in current environment) > > In falling back, I would use the same current (not DR) XCF/CFRM/WLM/LOGR > > so I would use the same LOGR and WLM for DR and 'prod' > > no chance of messing up 'prod' > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DR Sysplex Procedure
Yes, I would IPL with a different loadparm to point to COUPLExx with DR XCF and CFRM but WLM and LOGR would not change (use same ones as in current environment) In falling back, I would use the same current (not DR) XCF/CFRM/WLM/LOGR so I would use the same LOGR and WLM for DR and 'prod' no chance of messing up 'prod' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DR Sysplex Procedure
Are you talking LOGR and WLM CDS's in the couplexx member? if so as long as they are defined in the DR's COUPLExx member Carmen Vitullo - Original Message - From: "Elaine Beal" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, October 16, 2019 11:52:43 AM Subject: Re: DR Sysplex Procedure So, both systems down IPL LPAR1 with new XCF and CFRM, use existing LOG and WLM files Will that cause an issue falling back? by using the same LOG and WLM files? Thanks, Elaine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DR Sysplex Procedure
So, both systems down IPL LPAR1 with new XCF and CFRM, use existing LOG and WLM files Will that cause an issue falling back? by using the same LOG and WLM files? Thanks, Elaine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DR Sysplex Procedure
Kees, thank you. I see that would not work and it would be better to have both systems down and IPL one at a time. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DR Sysplex Procedure
"Do both LPARs need to be down (not desirable) before IPLing either of them with the new CF and XCF?" I would try to test the real situation as much as possible. Besides, I think it will not work. LPAR's don't join each other, they join a Sysplex. After ipling one system with the new definitions, it runs from different Couple datasets and is a Sysplex of its own, but with XCF connections to the other LPAR that runs from the old Couple Datasets, so in the old Sysplex. This seems asking for unexpected problems. Kees > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Elaine Beal > Sent: 09 October, 2019 16:17 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DR Sysplex Procedure > > We are planning to test a remote copy sysplex environment and I would like > to test it in our home DEV environment > PROD data will not be accessible during the DR test so PROD sysplex should > not be affected > > To test in DEV I have defined a new XCF and CFRM since I will need to do > that for DR > to account for the different CPU serial number. > In DEV I have not changed the serial number for the test, I'm just trying > out the procedure. > > At DR we will IPL the sysplex LPARs one at a time so I'm not concerned > about the order, the files or the join. > > I'm not sure about the order for DEV. > > Do both LPARs need to be down (not desirable) before IPLing either of them > with the new CF and XCF? > Or is one at a time okay since one is removed from the sysplex at shutdown > and just won't be able to join the current one at IPL > > I am not planning to create new LOGR and WLM files at DR but I will need > to create them for the test as they are shared. > > so, the plan is- > > 1. create new XCF and CFRM DR files (new LOGR and WLM for testing DEV at > home but not at DR) > > 2. update COUPLXX with new files > > 3. shutdown LPAR1 > > 4. IPL LPAR1 with new COUPLxx and respond toinitialize new files > > 5. Shutdown LPAR2 and IPL with new COUPLxx (no initialize) > > Thanks, > Elaine > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DR Sysplex Procedure
We are planning to test a remote copy sysplex environment and I would like to test it in our home DEV environment PROD data will not be accessible during the DR test so PROD sysplex should not be affected To test in DEV I have defined a new XCF and CFRM since I will need to do that for DR to account for the different CPU serial number. In DEV I have not changed the serial number for the test, I'm just trying out the procedure. At DR we will IPL the sysplex LPARs one at a time so I'm not concerned about the order, the files or the join. I'm not sure about the order for DEV. Do both LPARs need to be down (not desirable) before IPLing either of them with the new CF and XCF? Or is one at a time okay since one is removed from the sysplex at shutdown and just won't be able to join the current one at IPL I am not planning to create new LOGR and WLM files at DR but I will need to create them for the test as they are shared. so, the plan is- 1. create new XCF and CFRM DR files (new LOGR and WLM for testing DEV at home but not at DR) 2. update COUPLXX with new files 3. shutdown LPAR1 4. IPL LPAR1 with new COUPLxx and respond toinitialize new files 5. Shutdown LPAR2 and IPL with new COUPLxx (no initialize) Thanks, Elaine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
