Came up with a simpler (at least it is to me) solution:
MACRO
&LABEL $DC &DATA
GBLB &DEF_DSECT
AIF (&DEF_DSECT).DSECT
DC &DATA
MEXIT ,
.DSECT ANOP ,
&END SETA FIND('&DATA', '''(')
&OUT SETC '&DATA'(1,&END-1)
&LABEL DS &OUT
.MEND ANOP ,
MEND
MACRO
&LABEL $EQU &DATA
GBLB &DEF_DSECT
AIF (NOT &DEF_DSECT).MEND
&LABEL EQU &DATA
.MEND ANOP ,
MEND
MACRO
&LABEL KEYFIELD &NAME,&FIELD,&TYPE=C,&DSECT=NO
GBLB &DEF_DSECT
AIF ('&DSECT' EQ 'YES').KEYFIELD_DSECT
&DEF_DSECT SETB 0
&FIELDLEN SETC 'L''&FIELD'
&LABEL DS 0F
AGO .KEYFIELD_GEN
.KEYFIELD_DSECT ANOP ,
&DEF_DSECT SETB 1
&FIELDLEN SETA 0
KEYFIELD DSECT ,
.KEYFIELD_GEN ANOP ,
KEYNAME $DC CL8'&NAME'
KEYDISP $DC A(&FIELD.-BASE) OFFSET TO FIELD
KEYDLEN $DC A(&FIELDLEN) FIELD LENGTH
KEYTYPE $DC CL1'&TYPE' FIELD TYPE
DS 0F
AIF ('&DSECT' EQ 'NO').KEYFIELD_END
KEYLEN EQU *-KEYFIELD
.KEYFIELD_END ANOP ,
MEND
Very little "override" now and takes care of the symbol table. I could
probably use OPSYN to replace DC/DS and EQU in the macro definitions but
this works for me.
Thanks for all of the input!!!!
*Mark*
On Wed, Jun 25, 2025 at 2:36 PM Jon Perryman <[email protected]> wrote:
> On Tue, 24 Jun 2025 14:02:46 -0500, Mark Hammack <[email protected]>
> wrote:
>
> >&DISPVAL SETC '(&FIELD.-BASE)'
> >&DISPVAL SETC ''
> >KEYDISP&UID &DC A&DISPVAL OFFSET TO FIELD
>
> Using &DC as DS simplified the solution. Out of curiosity, what was your
> reason not to have the definition on the &DC statement and use blanks to
> make it a comment? For example:
>
> &SEP SETC ' *** COMMENT FOR DS *** '
> &SEP SETC '' Uses field data for DC
> >KEYDISP&UID &DC A&SEP.(&FIELD.-BASE) OFFSET TO FIELD
>
> >It winds up potentially adding a lot to the symbol table but is much
> >clearer (in my opinion) than what I originally had.
>
> ROTFLOL. Consider the worst possible scenario (a million fields and 1,000
> programs). Most of those programs will rarely if ever be assembled once
> each year. For those that are constantly changing, your design allows for
> data only csects to allow the constantly changing program code to eliminate
> the generated data.
>
> Remember, IBM doesn't worry about labels so why should you if you do it
> appropriately. As an example, look at the TSO command parser macros that
> generate multiple labels for every option.
>
