You can hypothesize objections to my hypothetical example. The example is nonetheless instructive: there are situations where it would be clearer to express the immediate operand of AHI or LHI as two bytes, not as a single expression. Is it the most important shortcoming facing the mainframe? Of course not.
Were I to rebut each of your hypothetical objections you could of course rebut my rebuttals. I will only point out that often the coder does not have control over how flags are defined: they are defined in some system or "external" DSECT or similar. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Mark Boonie Sent: Wednesday, March 1, 2017 7:53 AM To: [email protected] Subject: Re: HLASM anomaly > It is perhaps a silly example. But suppose R1 was to contain a pair of > flag byte values. Suppose the flags were equated. Now it might make > sense to code > > LHI R1,2AL1(MYFLAG1) > > Or something like that. Yes you can code the following but it is no > great exemplar of coding clarity: > > LHI R1,MYFLAG1*256+MYFLAG1 I probably wouldn't define them as two bytes of flags. Instead, I'd define them as a single two-byte field of flags: MYFLAGS DS XL2 FLAG1 EQU X'8000' FLAG2 EQU X'4000' Etc. Setting bits is pretty clear: LLILL R1,FLAG1+FLAG3+... Plus, you don't have a field of flags being treated as signed, which most likely isn't what was intended. Also, this way it would be clear that the flags need to be contiguous so that they can be operated on as a unit, and I don't have to worry that in a few years someone will rearrange the data area and insert another field or two between the two bytes of flags. - mb
