The one exception that comes to mind is a label on a macro which has a keyword RELATED=xxxxxxxx, where xxxxxxxx is somehow supposed to be a clue as to where in the source code is the macro which does the opposite of the first macro. E.g., GETMAIN and FREEMAIN do opposite actions with the same piece of virtual storage, as do STORAGE OBTAIN and STORAGE RELEASE. Other pairs are ATTACH and DETACH, etc. The only way I have ever found to "relate" one macro with another that does the opposite is via labels on both macros, such as GETDSA STORAGE OBTAIN and FREEDSA STORAGE RELEASE. This is one of the reasons why I don't use the RELATED= keyword very often any more. It seems so useless, and I have never found a macro that imposed any rules on the RELATED= keyword, such as requiring that the value coded be found somewhere within the same assembly.
Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: [email protected] * w: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of McKown, John Sent: Tuesday, June 05, 2012 6:52 AM To: [email protected] Subject: Re: DS 0H > -----Original Message----- > From: IBM Mainframe Assembler List > [mailto:[email protected]] On Behalf Of glen > herrmannsfeldt > Sent: Monday, June 04, 2012 4:24 PM > To: [email protected] > Subject: DS 0H <snip> > Oh, yes, in the general case I agree. It just seemed unneeded in this > specific case. > > -- glen I agree, in this specific case, it is unneeded. But it is my general technique to do this. So why be different just because it is likely unnecessary? My rule for most instructions is "place any required label on a separate DS 0H as the preceding statement." The main exception is when the instruction is used as "data", such as the target of an EX instruction. John McKown
