Ah, my "no subject" post was rejected by the tooling. >I assume the repair is to test the correct bit, ignoring the >correct store of the system clock.
The assumption is incorrect. >Are all defective macros (even non-GUPI) repaired? There are no macros involved. The fix is complete. >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. This is indeed what was done. The main problem with any other approach is that the "lots of places" are not limited to IBM load modules. They can be packaged with any application (IBM-owned, ISV-owned, customer-owned). That is the nature of callable services stubs (which is where the erroneous code is). Thus the fix makes things so that those stubs will always report "available" because as of z/OS 1.10 it *is* available (and if someone has reason to change those stubs, future versions of the stubs might not have the test at all). The error was not only testing the wrong byte. The error was also in checking for "off" instead of "on". Thus the test succeeded whenever the bit was off. As of Dec 15, the bit will be on and things break. Up until the clock gets to X'E....' (when things would start working again) and then back off again when it gets to x'F....'. Thus Tony's correct that this is a little incomplete: >...[fails] when the create time of the UCCB time is >D0000000 0000000 or greater It wasn't a question of "didn't go very far with testing" but with not bothering to discuss something that is likely of no practical relevance (and perhaps being a bit careless in the details -- no one really needed the detail about the clock value either). No one really needed to know that it will be broken between 2015 and 2024, then work again until then 2033, then be broken again until 2042 (or whatever the dates are). It was plenty to know when things break. As with many things, the less said the better. Adding unnecessary details sometimes serves little purpose other than to introduce opportunity for having error in those details. 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
