On 2015-10-15, at 21:06, J O Skip Robinson wrote: > I'm piecing together various clues. It appears to me that: > > 1. The UCCB is a defined control block, mapped in several (!) MACLIB members > such as CUNBAIDF. > A more modular design might map it in one macro and call it from all the others. Jurisdiction probably precludes.
> 2. Various flags are defined beginning at UCCB+10. > 3. Somehow during IPL the system clock has been overlaying UCCB+10 by > (presumably) Unicode set up processing. > 4. No one noticed all this time because the flag nibble in the timestamp has > always, coincidentally, indicated 'Unicode 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? > > I suspect that checks for the timestamp are far rarer than checks for Unicode > availability. So the fix is to store the clock somewhere else at IPL > (UCCB+20) and ensure that the critical flags are zero. Our PMR indicates what > I suspected: a zero value means OK, a one value means not OK. This is > analogous to the RACF flag in the CVT. Zero means that RACF is functional > while one means that it is not. I have a hilarious war story about how I know > that. > And I wonder how the problem was discovered. Does someone routinely test with the system clock advanced a few weeks; long enough for an APAR to turn around? May I infer from "Our PMR" that you're the reporting site? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
