Written off the top of my head so it might have coding errors
MACRO
MYMACRO &VALUE,&DSECT=NO
AIF ('&DSECT' EQ 'YES).DSECT GBLA &V&V SETA &V+1 &NEXTV SETA &V+1
AGO .CONT
.DSECT ANOP ,&V SETC ' '&NEXTV SETC ' 'MYMACRO DSECT ,
.CONT ANOP ,
START&V DS 0DA&V DC A(&VALUE)B&V DC A(START&NEXTV) point to next entry
MEND
Alternative to a counter is to use &SYSNDX.
On Thursday, June 19, 2025 at 10:21:32 AM PDT, Mark Hammack
<00001b4f3fed68ca-dmarc-requ...@listserv.uga.edu> wrote:
I just read Ed Jaffe's presentation from Share where he mentioned that they
have some macros that not only generate a DSECT but using the same macro,
generate data in the program. I can find (and have a few) examples of
doing that when the data occurs once in a program but am drawing a blank on
a good way to do that for multiple occurrences of the macro.
I've come up with two solutions but think there has to be a better way.
The first solution is to have a separate section in the macro for the DSECT
vs. the code generation such as:
MACRO
MYMACRO VALUE,&DSECT=NO
AIF ('&DSECT' EQ 'YES').DSECT
DC A(VALUE)
MEXIT
.DSECT ANOP ,
MYMACRO DSECT ,
MYVALUE DS A
MEND
The problem with this is keeping the two sections 'in sync'. We've run
into issues where the code gen part was updated but not the DSECT part or
vice versa.
The second solution works but is kind of 'ugly':
MACRO
MYMACRO VALUE,&DSECT=NO
AIF ('&DSECT' EQ 'YES').DSECT
&V SETC '&VALUE'
&LAB SETC ' '
AGO .GEN
.DSECT ANOP ,
&V SETC '0'
&LAB SETC 'MYVALUE'
MYMACRO DSECT ,
.GEN ANOP ,
&LAB DC A('&V')
MEND
This works ok for mapping small amounts of data, but would become unwieldy
with more than a few entries (few is relative to how patient you are).
Fortunately, the cases where this is convenient (table entries) tend to
only have a few fields (in my case). It also gets to be a bit crazy if
there are positional and named variables.
Looking through SYS1.MACLIB and SYS1.MODGEN, it looks like the macros are
such that there are separate macros for generating a table entry and the
DSECT or IBM assumes the macro will only be used one time in a program.
Sorry for the formatting. Limitations of Gmail.
*Mark Hammack*
Systemware, Inc.
mark.hamm...@gmail.com
214-478-0955 (c)
