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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
