Yes, the macro language is flawed, but I'm used to it and have no issue with using it heavily.
Labelled and qualified USING might make the whole exercise unnecessary, depending on the details. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Jon Perryman <[email protected]> Sent: Saturday, June 21, 2025 11:29 PM To: [email protected] <[email protected]> Subject: Re: Using the same macro to create the DSECT and a table entry External Message: Use Caution On Fri, 20 Jun 2025 10:46:21 +0100, Jonathan Scott <[email protected]> wrote: >You'd be amazed at what can be done using OPSYN to intercept DC, DS, ORG and >EQU! I agree that OPSYN is powerful that has solved multiple problems for me but remember the solution to the problem changes the problem. This is certainly one way to solve the problem. Macro language has many blemishes and it's not a language that I want to write on a daily basis. AIF, AGO and other statements are barely tolerable but macros make HLASM a great language. Structured macros (if, else, endif, while, ...), I/O and much more. > I would recommend that rather than defining prefixed labels > for each instance it would be much better to use anonymous fields > except for the standard DSECT then to use qualified USING statements No one suggested a qualified USING. Instead, the suggestion was creating unique labels that are never referenced (except in chaining if needed) and the USING only references. What is the downside to labels that never get referenced? For lesser experienced, a single statement is far easier to understand than it being modified depending upon a macro. > I've previously written tools to support "object oriented" assembler "class" > definitions > But admittedly that stuff was very tricky to set up and it took a lot of work > to make it sufficiently reliable, > robust, well-documented and maintainable to be suitable for official product > code, so it's not really a quick solution. OOP is overrated. So much so that GO does have the concept and Google designed the language to require rewriting code over converting it to GO. Macro language gives HLASM the ability to emulate and quickly implement features from other languages. For instance, our DCB and I/O macros provide the important parts of OOP much in the same way as GO.
