HLASM includes code which interfaces to system services for z/OS, VM/CMS, z/VSE and Linux, using standard assembler techniques. If you have full control over the creation of some flag definitions, the simplified TF/CF/SF method using the length value can optionally be used for keeping the code simple. If not, you just use standard methods. If you can't tell the difference, you shouldn't be writing code.
Jonathan Scott -----Original Message----- From: IBM Mainframe Assembler List <[email protected]> On Behalf Of Jon Perryman Sent: 17 February 2026 21:08 To: [email protected] Subject: Re: Apparent Test Under Mask Failure On Tue, 17 Feb 2026 18:00:28 -0000, Jonathan Scott <[email protected]> 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, As application software, HLASM can completely follow the L' standard. Those of us writing system software don't have that luxury ( 4 data areas volumes don't support L' flags). You can't have a standard that is only valid half the time. > which eliminates a very common source of errors, especially as option > flags may move to different bytes from one release to another The solution to the problem only changes the problem. Will those people working on system software notice when they should have coded L' versus when not to code it. There are solutions to this but you must fully understand the problem. Which of the following follows the standard and works correctly? TCBCSTEP, L'TCBCSTEP, USRACTV, L'USRACTV, TM C'A', TM x'C1', TM b'11000001' During a code review, which are most likely to be questioned?
