All, the document I referred to was a SHARE presentation. I have uploaded it at https://bixoft.nl/John%20R.%20Ehrman%20-%20Assembler%20Language%20as%20a%20Higher%20Level%20Language%20-%20Macros%20and%20Conditional%20Assembly%20Techniques.pdf
The part about bit handling starts at slide 114. Kind regards, Abe === On 17/02/2026 19: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. > > Jonathan Scott > > -----Original Message----- > From: IBM Mainframe Assembler List <[email protected]> On > Behalf Of Jon Perryman > Sent: 17 February 2026 16:38 > To: [email protected] > Subject: Re: [External Sender] Re: Apparent Test Under Mask Failure > > On Tue, 17 Feb 2026 10:06:03 +0100, Abe Kornelis <[email protected]> wrote: > >> I disagree wholeheartedly with anyone who claims that the length >> attribute of a bit EQU should not be used to contain a copy of its >> value - or anything else for that matter. > L' for flags is totally unacceptable. Show us 1 instance in the 4 volumes of > the z/OS data area's that allows you to code L'flagname. > > Using C'x' for flags is totally unacceptable. Again, show us 1 instance. > > Both cause confusion leading to coding errors. I've only seen this technique > used outside of vendor products. > >> Not only was it good enough for Dr. John Ehrman - he liked it enough to >> spend a large presentation on the technique. > Can you point us to this presentation? Dr. Ehrman never convinced IBM to use > this technique. I would like to know why he considered it a good technique. > >> The assembler has always given us freedom of expression. > Assembler is very powerful but it's no excuse to abuse it to the point of > causing confusion.
