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 <
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)
>
