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
[email protected]
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of J Ellis
Sent: Tuesday, August 01, 2017 9:04 AM
To: [email protected]
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 [email protected] with the message: INFO IBM-MAIN
