Compatibility is critically important.
Even small changes can have unforeseen compatibility impacts.
When we allowed decimal self-defining terms to be negative, we
thought that was harmless, as self-defining terms have always
been allowed to be negative if expressed as binary, hexadecimal
or character values. But users had existing macros which were
for example relying on negative decimal values not having type
attribute 'N', which had to be changed after that enhancement.
We looked into the old problem of negative SETA values being
substituted without a sign long ago, but rapidly identified some
internal cases where including the minus sign would break
existing macro code. The SIGNED built-in function was
introduced as a partial workaround.
We have been considering the following two enhancements:
1. FLAG(SETAABS|NOSETAABS).
The option FLAG(SETAABS) issues a warning whenever a SETA
symbol is substituted into a character expression or source
statement and the absolute value differs from the signed
value (that is, when the value is negative).
2. COMPAT(SETAABS|NOSETAABS).
The option COMPAT(NOSETAABS) prefixes the value with a
minus sign whenever a negative SETA value is substituted
into a character expression or source statement.
The FLAG option would still apply when COMPAT(NOSETAABS) is
specified, as a means of detecting cases where the output would
be different from the original implementation.
For compatibility, the defaults would of course have to disable
the new enhancements, so it would be necessary to enable these
if required.
However, if common product-related macros may be relying on the
lack of a sign, changing the results could cause problems. For
this reason, I think it would be better to implement the FLAG
option first, so that we can get an idea of how common this
problem might be before we decide whether to provide the option
to fix it.
Gil writes:110:23, Seymour J Metz wrote:
> > Metz's Law: You may be good at arithmetic but the assembler is better
> > .
> Except for negative SETA values.
>
> How did that happen and why wasn't it fixed promptly
> or ever? Lexical entanglement?
Jonathan Scott, HLASM
IBM Hursley, UK
