That's what we do (did) for a 3rd site DR test when new couple datasets were newly formatted
CFRMPOL(CFRMDR) CFRMOWNEDCFPROMPT(NO) The sysplex couple datasets were formatted prior to DR with the policy name, restored at that site from our monoplex (rescue) system. in this case a VM image emulating a CF so the policy contains.... TYPE(SIMDEV) MFG(IBM) Carmen ----- Original Message ----- From: "Jesse 1 Robinson" <[email protected]> To: [email protected] Sent: Tuesday, July 25, 2017 10:13:32 AM Subject: Re: What casues IPL/XCF to read the CFRM data set for the policy ? Our experience with DR recovery is that IPLing 'multisys' with a freshly formatted sysplex couple data set can succeed only if PARMLIB COUPLExx specifies the policy name to use via CFRMPOL() because there is no recorded policy-in-use. The policy to be used use must already have been stored in the CFRM couple data set before IPL. If COUPLExx does not contain CFRMPOL() naming the intended policy, I don't believe that a cold start IPL could have succeeded. . . 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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Barbara Nitz Sent: Monday, July 24, 2017 10:24 PM To: [email protected] Subject: (External):Re: What casues IPL/XCF to read the CFRM data set for the policy ? >soon after the system were up and verified, an incorrect policy0 was written >into the CFRM data set, had the wrong serial number and wrong partion number >for the CF LPAR. >both systems have been IPL'd successfully multiple times since the install. Not surprising. You must have activated the first policy at some point - or it got autoactivated due to a new/empty CFRM CDS during that first IPL. If you write a new policy but don't activate it, that is a ticking time bomb, but is fine, too, across IPLs since XCF will always use the last *active* policy in the CFRM CDS - slot 0. The one that was originally (and later incorrectly) written is in (let's say) slot 1. As far as I know, the only way a CFRM policy gets 'auto-activated' is when you have a CFRM CDS *without* an active policy in it. You only get that by redefining the couple CDS. In every other case, an active poliy exists in slot 0 and will be used. A policy only gets to slot 0 by getting activated. What I don't know is how the situation is when you have activated a second policy (even by the same name), but you never got the 'policy xyz now active' message. After the setxcf activate command, there should have been messages stating that 'n changes pending'. >on Sunday last, the IPL's failed, becasue XCF couldn't find the CF - because >of the incorrect policy0 overlay I mentioned above. Again, we have been fine >since April in this state. >the only change we can identify at this time is we took the volumes that the >XCF data sets live on OUT of PPRC on Friday. >It appears that the flawed policy0 has been lurking in the CFRM data >set since the install, but was never activated until this last Sunday. >So, we are trying to determine what caused the data set to be used If it were me, I would read carefully through all hardcopy logs from all IPLs, checking the messages about which CFRM CDS on which volume was used plus all messages after the wrong policy was written, looking out for setxcf commands, for CDS switches and for incomplete activations, especially *after* PPRC was cut. Your JES3 global did not wander to the second system, did it, so that the last one down in the plex is not the first one up? Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
