As the Perl folks say, TMTOWTDI. I typically use the label on the macro as the label on the DSECT, skipping the DSECT if the label is omitted. For individual fields, I either use a prefix for all of the labels or I use a macro that conditionally drops labels and AIF around EQUs.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> on behalf of Mark Hammack <00001b4f3fed68ca-dmarc-requ...@listserv.uga.edu> Sent: Thursday, June 19, 2025 1:20 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU <ASSEMBLER-LIST@LISTSERV.UGA.EDU> Subject: Using the same macro to create the DSECT and a table entry External Message: Use Caution 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)
