Sorry, I was trying to keep it simple. Here's a slightly more complicated
example:
MACRO
&LABEL MYMACRO CODE,RTN,&DSECT=NO
AIF ('&DSECT' EQ 'YES').DSECT
&LABEL DS 0F
DC F'&CODE'
DC A('&RTN')
MEXIT
.DSECT ANOP ,
MYMACRO DSECT ,
CODE DS F
ROUTINE DS A
MYLEN EQU *-MYMACRO
MEND
...
TABPTRS DC A(TABLE,MYLEN,TABLE_END)
TABLE MYMACRO 1,ROUTINE1
MYMACRO 2,ROUTINE2
...
TABLE_END DS F
MYMACRO 15,ROUTINE15
...
LM R15,R1,TABPTRS
USING MYMACRO,R15
JUMPER DS 0H
C R2,CODE
JE DOIT
JXLE R15,R1,JUMPER
* bad entry code handler
DOIT DS 0H
L R15,ROUTINE
BASR R14,R15
DROP MYMACRO
I've used this nomenclature many times successfully. It only becomes an
issue if someone changes one part of the macro (ex: add a variable before
CODE in the DSECT) but not the other. Maybe it will get picked up during
assembly, maybe it won't.
*Mark*
On Thu, Jun 19, 2025 at 1:31 PM David Clark <[email protected]> wrote:
> You don't give a use-case example. So, it is hard to suggest a
> coding solution. But, to my imagination, I would just code it along these
> lines.
>
> MACRO
> &LABEL MYMACRO VALUE,&DSECT=NO
> AIF ('&DSECT' NE 'YES').GEN
> MYMACRO DSECT ,
> .GEN ANOP ,
> &LABEL DC A(VALUE)
> MEND
>
> If you want to prevent accidental duplicate DSECT headers being generated,
> just use a global variable boolean test to bypass it as needed.
>
> Sincerely,
>
> Dave Clark
> --
> int.ext: 91078
> direct: (937) 531-6378
> home: (937) 751-3300
>
> Winsupply Group Services
> 3110 Kettering Boulevard
> Dayton, Ohio 45439 USA
> (937) 294-5331
>
>
> On Thu, Jun 19, 2025 at 1:21 PM Mark Hammack <
> [email protected]> 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.
> > [email protected]
> > 214-478-0955 (c)
> >
>
