I'm troubled by the suggestion that *anything* can be done at IPL time if a policy to be force-activated has incorrect serial and or partition number. If so, that policy is useless. If a workable policy was previously overlaid ('replaced') by a different policy of the *same name*, then it's brick wall time. The only resolution is what was actually done in this case. Bring up the system in GRS ring mode--avoiding dependence on a nonexistent GRS structure--in order to recreate and activate a usable policy.
You should not have to IPL again at that point as all move-to-sysplex steps that I can recall from 20 years ago (!) are dynamic. However, our automation policy is designed to work from IPL up, so that might be simpler in the long run. Again, I can't urge strongly enough to use a new name for a new policy. If POLICYA and POLICYB are both stored in the CFRM data set, you can point to the last working policy at IPL time. If XCF finds more than one policy in CFRM, he could prompt to use a different policy than the one last in use. That's the only useful workaround I can imagine. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of J Ellis Sent: Tuesday, August 01, 2017 9:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: APAR'd Re: What casues IPL/XCF to read the CFRM data set for the policy ? Agree with all your comments. I have asked for an operator command that shows exactly what/why there is a pending condition. And especially a message at IPL time that something is wrong or there are inconsistencies -- what do you want to do now ? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN