Agree, I see possibly a new IXC message, WTOR for the operator to respond to Verify automatic activation of CFRM policy CFMRPOLN Reply "U" or 'N' to keep CFRMPOLO as the active policy
----- Original Message ----- From: "Kees Vernooij (ITOPT1) - KLM" <[email protected]> To: [email protected] Sent: Tuesday, August 1, 2017 9:44:27 AM Subject: Re: APAR'd Re: What casues IPL/XCF to read the CFRM data set for the policy ? After reading this several times, I wonder what the likely solution will solve: - It will bring the activation of the new structure forward to the first subsequent IPL i.s.o. an unpredictable IPL in the further away future. Depending on IPL frequencies, this event might be several weeks/months in the future i.s.o many week/months. I doubt if this will help in problem determination. - How can the new policy be activated in a Sysplex on 'the next ipl' of one system, if other systems in the Sysplex still have a connection to the old CF and possibly to the logrec structure? Will the connections be forced? And will the CF be forced from the Sysplex? - A solution could be to verify the new policy on activation and if conflicting situations are encountered, drop the activation i.s.o. leaving it pending. At that same moment, the customer is informed of the problem and can investigate what was wrong with the policy. Thanks, Kees. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of J Ellis > Sent: 01 August, 2017 16:26 > To: [email protected] > Subject: APAR'd Re: What casues IPL/XCF to read the CFRM data set for > the policy ? > > from IBM XCF: > "APAR OA53531 is now open to address this condition. > Our change will likely to cause the pending policy to be activated upon > the next ipl rather than waiting till the last failed-persisten str to > be > deleted from the to-be-deleted CF as encountered by this customer" > > here's the explanation as near as we have concluded - > (note that we because of the way our consoles are configured and the way > we use a scripting language to 'one button' IPL from client > workstations, we will never know what caused the original IPL to fail) > in April we installed a new CEC, it IPL'd successfully using the the > CEC's internal CF. > Shortly after the IPL a new policy with an incorrect serial number and > partion number was introduced via a SETXCF operator command. > this policy went PENDING and no one noticed for whatever reason. > it has been concluded that it went pending because the LOGREC structure > was marked persistent. > months go by with successful ipl's, with the 'bad' policy still pending > because of the logrec structure ... > > come a Sunday morning when most of tech support is on vacation :-) > > an IPL fails, and additional IPL's are attempted by operations, (we and > IBM are still researching the hardware logs to see if anyone can > determine original failure) > tech support is called and has the CF bounced, this clears the > connection issue, subsequent IPL fails because GRS can't find the CF, > because the bad policy is now current. > we IPL with GRS=NONE to get system up, see where the incorrect policy is > in place (looking at IXC messages from IPL) > write out correct policy and activate it. > re-ipl, all is good > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] 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 [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
