On 15 October 2015 at 21:06, Paul Gilmartin wrote: >> http://www-01.ibm.com/support/docview.wss?uid=isg1OA48941 >> > I'm curious: how (not when) does this problem occur? Is it some > OCO doing a TM on the wrong address? I suppose I should infer > something from: > > Problem summary > **************************************************************** > Correct the code involved to move the timestamp field to > allow the Unicode services active indicator to remain valid.
The Red Alert itself makes it reasonably clear. http://www14.software.ibm.com/support/customercare/sas/f/redAlerts/20150930.html "A recent problem was discovered in Unicode Services where the check for the availability of the Conversion Information service, introduced in z/OS 1.10, is checking the wrong bit in the Unicode UCCB to determine if the function is available. Unfortunately, the wrong bit happens to be within a timestamp reflecting the time at which the UCCB was created at IPL time. That bit in the timestamp will change when the system is IPLed on or after December 15, 2015, causing the availability check to fail and resulting in an error return code back to every caller of the service." Presumably they decided to move the timestamp field rather than whatever field the tested bit is in. Probably there are lots of places that test the (incorrect) bit, and just one that stores the TOD clock value there, so less code needed to change. Though the fix does seem to hit multiple modules... Perhaps the description in the APAR is misleading. It says "...[fails] when the create time of the UCCB time is D0000000 0000000 or greater. An identical request does not fail when the time is CFFFFFFF FFFFFFFF" Maybe they didn't go very far with testing "or greater". A typical flag-bit definition (ON means the service IS available) would fit the description in the Red Alert if the flag is bit 4. This bit has been on since June of 2011, so the code (written later than that, I believe) may have been testing it and finding all to be well since then. Following this reasoning, the bit would "right itself" in May of 2020. Bit 5 or even 6 might be possible if the code was implemented after the turn-on date for one of those bits, since once on, none of them goes off until the Dec 2015 rollover. Or of course the sense of the bit in question could be backwards (if ON then the service is NOT available), which allows for yet more possibilities. Well I guess this borders on reverse engineering. It's Friday... C800000000000000 = 2011-06-30 15:40:08.883200 bit 4 goes on CC00000000000000 = 2013-09-22 02:32:33.060864 bit 5 goes on CD00000000000000 = 2014-04-13 17:15:39.105280 CE00000000000000 = 2014-11-03 07:58:45.149696 bit 6 goes on CF00000000000000 = 2015-05-25 22:41:51.194112 D000000000000000 = 2015-12-15 13:24:57.238528 bits 4-7 go off D800000000000000 = 2020-05-31 11:09:45.593856 bit 4 goes back on F92CF59044F00000 = 2038-11-28 11:05:00.000000 Freedom 85 for me FFFFFFFFFFFFFFFF = 2042-09-17 23:53:47.370495 End of world as we know it Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
