Back in the 1960s, every byte that could be saved was very important, as the assembler had to run in a very limited partition size. My guess is that it did not seem important to support negative SETA substitution.
>From my previous research, cases which would be impacted by NOCOMPAT(SETAABS) >are probably very rare, and the FLAG(SETAABS) option could be used to track >them down. One would have to do further testing to find out whether for >example IBM product macros would need COMPAT(SETAABS). Sometimes IBM product >macros have been changed to tolerate the use of new HLASM options, such as >FLAG(PAGE0). And most COMPAT and FLAG options can be changed locally using >ACONTROL if necessary. The idea of introducing a signed variant of SETA seems totally disproportionate when all that's needed is an option to keep the sign. Jonathan Scott -----Original Message----- From: IBM Mainframe Assembler List <[email protected]> On Behalf Of Paul Gilmartin Sent: 17 February 2026 20:58 To: [email protected] Subject: Re: Absolute SETA substitution (was Re: Apparent Test Under Mask Failure) I wonder whether the aboriginal defect was the result of coder indolence or the prohibitively high cost of storage needed for the few instructions to preserve the sign. On 2/17/26 09:58, Jonathan Scott wrote: > Some years ago I produced a suggested design for fixing the SETA symbol > substitution "feature" of losing any minus sign but I hadn't got round to > implementing it by the time I retired (because of low customer priority), and > I don't know if it is on the future schedule. If I remember correctly, it > worked as follows (where keywords are provisional): > > - A new option COMPAT(SETAABS), where the NOSETAABS option includes the minus > sign (although for compatibility within a release the default must remain > compatible). > - A new option FLAG(SETAABS) which would issue a warning whenever a negative > SETA value is substituted into assembler text (regardless of the COMPAT > setting). Again, for compatibility the default must be NOSETAABS. > ... but that would introduce incompatibility between macros/copybook members needing opposite settings of the options. If it had been my choice, I would have provided not the signed() BIF but a new type of symbol: SETA yielding absolute value (compatible) SETS yielding signed value. -- gil
