from Gil: >I'm curious: how (not when) does this problem occur? Is it some >OCO doing a TM on the wrong address?
yes. It should have been testing a flag byte but, because of the error, was testing a byte that was not a flag byte but was the target of a STCK. from Skip: >1. The UCCB is a defined control block, mapped in several (!) >MACLIB members such as CUNBAIDF. The UCCB is not an interface and should not have been placed into any MACLIB member. This was part of the origin of the erroneous code. You may notice that while the mapping is there, there is no interface provided to locate the area. So while there is a mapping that is visible, it does not effectively constitute an interface. >2. Various flags are defined beginning at UCCB+10. Nope. What is defined at UCCB+10 is a timestamp. See the answer to Gil's question. >3. Somehow during IPL the system clock has been overlaying >UCCB+10 by (presumably) Unicode set up processing. Nope. See #2. >4. No one noticed all this time because the flag nibble in >the timestamp has always, coincidentally, indicated 'Unicode available'. Yup. And no one (apparently) tested "prior to z/OS 1.10 is this function available". By the way, it's not actually "Unicode available". It's "Unicode conversion services available". >5. As of the magic moment on December 15, the clock rolls over and >reverses the benign bit. Without the fix, Unicode appears >to be unavailable more or less forever. Until the bit once again >changes back? Not all of unicode, but these services. And "yes" (more specifically, until you re-IPL after the bit changes back -- in 18 or so years). 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
