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.

Reply via email to