Re: Symbol collisions in macro definitions

[David Eisenberg]

Jonathan,

That worked perfectly... thank you!

David

Re: Symbol collisions in macro definitions

[Seymour J Metz]

The syntax needs to distinguish between specifying the name space and 
specifying a labelled USING. If you submit an RFE, I'd suggest keeping it 
general and letting IBM decide on the syntax.

The dollar sign used in IBMAP is not available for HLASM, because it is allowed 
in identifiers, so that resolves your complaint.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf 
of Steve Smith [sasd...@gmail.com]
Sent: Monday, March 13, 2023 1:26 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Symbol collisions in macro definitions

Jonathan Scott's idea was what I thought of, (but I wasn't willing to work
through the details).

Shmuel (Seymour J.) Metz's reference to QUAL is interesting.  I'd modernize
the concept by using the standard '.' to delimit the qualifiers (I got
tired of the gratuitous use of "$" decades ago).  This seems to be very
similar to C++ namespaces (and structure elements), and it would be a very
useful addition to HLASM.

sas

Re: Symbol collisions in macro definitions

[Steve Smith]

Jonathan Scott's idea was what I thought of, (but I wasn't willing to work
through the details).

Shmuel (Seymour J.) Metz's reference to QUAL is interesting.  I'd modernize
the concept by using the standard '.' to delimit the qualifiers (I got
tired of the gratuitous use of "$" decades ago).  This seems to be very
similar to C++ namespaces (and structure elements), and it would be a very
useful addition to HLASM.

sas

Re: Symbol collisions in macro definitions

[Seymour J Metz]

Add a DECIMAL=[YES|NO] keyword and generate

AR10 EQU   10AR

when DECIMAL=YES is coded.

This seems like a poster child for implementing QUAL 
  from 
IBMAP . RFE?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf 
of David Eisenberg [deisenbe...@optonline.net]
Sent: Monday, March 13, 2023 12:36 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Symbol collisions in macro definitions

I'm hoping that someone can advise us. We have a small number of applications 
requiring IBM's IHAARA macro. The macro unconditionally generates this 
statement:

ARA  DSECT   ALLOCATION RETRIEVAL AREA

We also have a ubiquitous custom macro which generates register EQU statements. 
That macro is invoked from every one of our applications, and we can't easily 
get around that. Rather than equating access register 10 to symbol AR10, we do 
it this way:

ARA  EQU   10AR

And that was fine for ages... until we tried using the IHAARA macro.

It would be rather onerous for us to change the ARA symbol definition in our 
custom macro to prevent the name collision. Is there a recommended way to get 
around this in the small handful of our applications which must reference 
IHAARA?

Any advice would be greatly appreciated; thank you!

David

Re: Symbol collisions in macro definitions

[Jonathan Scott]

Here's an example of renaming the ARA DSECT to ARADSECT DSECT by
intercepting the DSECT statement using OPSYN:

 MACRO
.* Macro to include IHAARA changing ARA DSECT to ARADSECT DSECT
 ARADSECT ,
 MACRO
.* Inner macro to intercept DSECT
MYDSECT ,
 AIF   ('' NE 'ARA').KEEP Go if not ARA
ARADSECT _DSECT ,  Rename ARA to ARADSECT
 MEXIT
.KEEPANOP  ,   Not ARA DSECT
_DSECT ,  Define with specified name
 MEND
_DSECT   OPSYN DSECT   Save standard DSECT
DSECTOPSYN MYDSECT Redirect it to macro
 IHAARA ,  Get the IBM ARA area
DSECTOPSYN _DSECT  Restore standard DSECT
_DSECT   OPSYN ,   Cancel temporary definition
 MEND

Jonathan Scott, HLASM
IBM Hursley, UK