The FLAG(SETAABS) option could be useful just to detect possible errors in existing code, where a negative SETA value has lost its sign. Adding a new option like that only requires a standard pattern of option-processing code (plus documentation) and a new message (which also needs to be documented), plus a handful of lines to implement the check.
I think it would only take slightly more code to add the COMPAT(SETAABS|NOSETAABS) option to allow the sign to be preserved as programmers would expect. By default, this would continue to behave in the old way, and it would be necessary to use the FLAG option to check whether it was safe to override it in a particular environment. That's the whole purpose of COMPAT options - to ensure that we don't break old stuff when we introduce changes. If it was subsequently found for example that IBM z/OS product macros could be impacted, then it might be of limited use until such macros were fixed to tolerate it. In this particular case, as far as I remember, I trawled various internal and product macro libraries and found only one ancient case in an obscure macro where it expected a minus sign to be dropped. I also found several cases where the code apparently failed to allow for the theoretical possibility of a minus sign being lost (for example the reduced length of an omitted optional 8-byte name was stored as 1, although I don't know how that would be used), so from that sample the incompatible version of the option might work better. But I was searching using very simple tools (using CMS/TSO Pipelines to look for substituted variable references in non-conditional assembler statements which also appeared in the target name field of a SETA instruction, then checking them manually) so I could well have missed stuff. Implementing a new variant of SETA would be a disproportionately huge amount of work both in code and documentation. Since Assembler H, internal codes have been used to represent information such as conditional assembly statement types and tokens within expressions, and for many purposes all available codes are already in use, which has given HLASM development a few headaches when adding new function. Additional built-in functions were squeezed in by using multiple levels of codes, but any new conditional assembly statement would be very disruptive and would need an extremely strong justification. Jonathan Scott -----Original Message----- From: IBM Mainframe Assembler List <[email protected]> On Behalf Of Paul Gilmartin Sent: 18 February 2026 03:33 To: [email protected] Subject: Re: Absolute SETA substitution (was Re: Apparent Test Under Mask Failure) On 2/17/26 14:27, Jonathan Scott wrote: > ... > 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. > ... IBM might adapt its code to work under all settings of (hypothetical) new options. But it would impose a similar toleration burden on customer and ISV customer-facing code. I can't envision that a new variant of SETA would be more costly to implement than new options. -- gil
