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