On Tue, 24 Jun 2025 14:02:46 -0500, Mark Hammack <mark.hamm...@gmail.com> 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.
