On 2/17/26 11:00, Jonathan Scott wrote:
HLASM itself and various related tools are written using macros which rely on using the
length attribute to associate a value with a flag byte, normally as a mask but optionally
as a CLI/MVI value. The macros allow one to test a flag (TF) or set it on (SF) or off
(CF) using just the name of the flag, without having to specify the name and value
separately, which eliminates a very common source of errors, especially as option flags
may move to different bytes from one release to another (which means HLASM initialisation
code has to support old installation option files by migrating them as necessary). I'd
agree that it's not how the assembler length attribute was originally intended to be
used, but it's just another useful convention, for example like using "*-*" to
represent 0 in a context where it will be overridden dynamically. Flag bytes don't need
to use the length for any other purpose, so it doesn't cause any problems.
...
I agree. This should be affirmed in the User's Guide. That won't
end this argument but will move it to a different arena.
Is there any possible conflict with Future Directions?
Or with third party use such as DSECT-to-C-Header filters?
--
gil
