OK, what Peter said. I get a C- for the explanation part, but I think the method part is sound. We're now running R13 on sandbox with the fix in place. V2R1 to follow soon.
A note on circumvention options. If you are truly out of harm's way for this problem, I don't suppose you have to do anything. I personally would not want to bet the farm on that judgment, but Seymour has repeatedly bequeathed you the dog. The timestamp is stored at UCCB+10 only at IPL, so the current value will remain indefinitely until the next IPL. Regardless of your IPL schedule, keep in mind that any system failure--software or hardware--could cause an unscheduled IPL on or after Dec 15. Best to have the fix in place by then. OTOH you don't have to actually IPL in advance if you have the three fix elements in place in NUC, LINK, and LPA. If your system crashes, re-IPL will implement the fix and you will be OK. As long as you got it right. Another note. Our R13 system is fairly current but not pristinely so. All three fix elements were at base level, so the PTF installed without any requisites. The NUC element CUNMIIPL is a 77K standalone module--not part of IEANUC01--so it should be easy to drop into SYS1.NUCLEUS if you wish to defer IPL. . . . 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 Peter Relson Sent: Friday, October 16, 2015 5:39 AM To: [email protected] Subject: Re: (External):Re: Unicode services Red alert 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
