On Sun, 18 Oct 2015 18:58:27 -0400, Peter Relson wrote:
>
>>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).
>
This makes sense if the test was intended to report product capability,
not any user selectable option.
In the long run, it's advisable to clean up things sucn as those stubs
to avoid a secular growth of cruft. And likewise to remove needless
fields in those macros.
>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 ...
>
That might be the consequence of an empirical repair: a programmer may
have coded:
TM
BO
... and got undesered behavior, so decided to change to:
TM
BZ
I think you're saying the bit tested is unconditionally set to 0; never changed,
and the stubs are now just an inefficient implementation of TRUE.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
