I don't agree. I use label EQU * in a stream of executable instructions. I 
think it is clearer that the label represents a point in the logic flow, not a 
particular instruction, especially in situations like

        TM   some_condition
        JNO  Not_Whatever
Instructions dealing with the Whatever condition
Not_Whatever EQU *
        TM   other_condition
        Etc.

It makes it clear that Not_Whatever is the "exit point" for dealing with 
Whatever, not the name of the other_condition logic block. It is less error 
prone if one is inserts additional instructions that follow the "whatever" 
logic and are not part of it. 

Revealing my age, I got into this habit in the days of programs on card decks. 
MUCH more convenient and less problematic to have every piece of "stuff" on a 
separate card.

I also think it is perfectly fine for labeling the end of an area of storage 
(DSECT). Sometimes you want the length, sometimes you want the end, such as 
when indexing through the entries in a table. LA R5,Next_Entry is clearer to me 
than AHI R5,Entry_Length.

Anything can be abused.

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Steve Smith
Sent: Wednesday, August 1, 2018 9:34 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: EQU * considered harmful

EQU * is a very common idiom in assembler programming.  I'd like to submit
for your consideration that it is wrong, 100% of the time.

Any symbol referencing memory should always be defined with DS/DC, so the
correct alignment can be specified.  * per se, is a very useful concept,
just not on EQU.  But as far as I can see, every EQU * is a bug, either
latent or actual.

The most acceptable usage would be to generate the length of an area (*-X),
but even that can easily be done by defining an 'end' symbol, so that EQU
X-Y is available.

If I'm overlooking something, I hardly have to ask... but tell me if
there's no better way for some example.

-- 
sas

Reply via email to