gil writes: > > 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. There is some truth in this, but I think this is putting it too strongly!
On the other hand, as I said: > We sometimes have to make an exception if a program is in error > but HLASM failed to detect it. This is a very difficult balancing act. It is critically important to minimize the risk of breaking existing programs when introducing enhancements or fixes. The support for negative decimal self-defining terms was prototyped several years before it was released, but delayed because of theoretical incompatibility concerns, even though none of our thousands of existing regression tests ran into any problems. We were then told that the largest negative number caused errors in assembler code generated by two compilers, requiring workarounds, and a customer reported the same problem, so we decided to go ahead anyway. In theory, we can use compatibility options to cover possibly incompatible changes, but that is a very blunt weapon. One Assembler feature that we are stuck with for compatibility reasons is that any minus sign is quietly lost when a SETA symbol is substituted in code or a character expression. We considered changing that and adding a compatibility option, but found that existing code which already allowed for that oddity would then quietly give incorrect results, for example if a macro explicitly inserted a minus sign when the value to be substituted was negative. In the meantime, the SIGNED function can be used as a workaround. Jonathan Scott, HLASM IBM Hursley, UK
