I wish we could take credit for discovering the problem. I've learned that many sites do time-warp testing on a regular basis. Remember the Y2K Flash Mob scene when we all did that incessantly? I seriously doubt that this problem was discovered by IPLing at Dec. 15. There was undoubtedly some further future date being explored. Whoa! Unicode is broken. Eventually it was narrowed down by the original customer (wishful thinking) or more likely by IBM to the actual fail point.
Our PMR was opened by a diligent colleague who wanted more specific details. And I appreciate that IBM complied and supplied more details, especially the SAMPLIB pointer, which allowed us to test without the painful need to change the system time at IPL. OK, I warned about a RACF war story. A DB2 sysprog was trying to debug what looked like a RACF problem in DB2. She found a flag documented in DB2 as 'RACF available'. She could see that it was zero, so she zapped it to one. This was not a DB2 control block but the actual MVS CVT flag. The entire system stopped working. Every RACF access of any kind resulted in a WTOR requesting permission to allow access. Somehow we got the flag zeroed out before total system collapse. Luckily it was the development system, and luckily we didn't have to IPL. But that's how I remember the meaning of the RACF flag. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Thursday, October 15, 2015 8:23 PM To: [email protected] Subject: Re: (External):Re: Unicode services Red alert 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 [email protected] with the message: INFO IBM-MAIN
