On 7/7/22 15:42:28, Jonathan Scott wrote:
The general rule is that HLASM programs which assemble without
error should always continue to generate compatible binary code, ...
Ouch!
A consequence of this "general rule" is that various HLASM
bugs, even some which result in behavior contrary to the
Ref., can never be fixed because to do so would break
compatibility. Rather, the misbehavior must be preserved
and documented as a feature. As a result, HLASM and its
specification become a crazy quilt of accommodations
to historic misbehaviors.
A couple anecdotes with what I consider happy endings:
Some decades ago, IBM fixed a code generation bug
affecting a construct we had been avoiding because the flaw
was widely known. Happily, I reported to our development
manager that we would no longer need to sidestep that
construct. He wasn't pleased; he insisted that we compare
all our SYSPUNCH files before and after the PTF to verify that
they were unchanged. There were no changes.
Somewhat more recently, we chose to switch from HLASM to
an ISV cross assembler for resource and performance reasons. A
co-worker said that he couldn't make the switch
because the cross assembler gave RC=4 on one of his
programs where HLASM gave RC=0. I inspected his code
and concluded HLASM was wrong. I opened an APAR and
IBM issued a PTF to issue the same RC=4. He resentfully
made the switch. His code did not depend on the bug.
A lees happy ending: Once I reported in this forum that a
different ISV assembler correctly reported a base-
displacement failure in a case where HLASM simply
generatedd incorrect code. The ISV saw my message and
modified his assembler to generate the same incorrect code,
for compatibility.
Fix the damned bugs, even "SETA -42"! Don't even make
incorrect behavior an option.
Thankfully, I note there's an independent standard for "C".
IBM can't cast its mistakes in stone.
--
gil
