I haven't seen that Red Alert but my guess is that it is STP related; STP provides that non-z/OS persistent data store that can cross IPLs. I know that an Epoch change in STP can prevent zos joining sysplex and requires sysplex-wide re-ipl, for example -- one of the rather rare sysplex-wide failures, though to zos's credit even that doesn't cause an outage. STP also has options of how Epoch changes are (mis)managed. Always wondered about STP design, but I don't know the constraints they had, it never seemed up to the standards of the rest of the system.
On Wed, Jun 26, 2024 at 10:07 PM Peter Relson <[email protected]> wrote: > Gil wrote > <snip> > Eerily reminiscent of a Red Alert IBM issued a couple years ago. A macro, > customer facing therefore hard to change, was doing a STCK to a wild > address. When a certain bit in the TOD changed, IPL cod which tests that > bit with no effect other than to crash when it had the wrong value would > make the next IPL impossible. > </snip> > > That seems unlikely, and almost inconceivable unless you IPL without > "clear" (aside from if the corrupted storage got written to a data set that > was read upon re-IPL). > > Might you have any details? > > I certainly understand relatively unpredictable side effects within the > current IPL, > > Peter Relson > z/OS Core Technology Design > > > ---------------------------------------------------------------------- > 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
