It ain't gonna happen, of course, but what would be really nice would be if every macro had a consistent way of specifying @Peter's "four [or more?] choices." The problem is often not so much the lack of a particular macro operand choice, but rather (just as one example) that one does not remember whether for this particular macro (R2) means that the value is in R2 or the value is in a fullword pointed to by R2. One has to go the manual and parse the description carefully to find out.
The VSAM macros support a variety of address formats like (*,scon). I'm not terribly fond of them, but at least it was an attempt at a universal, flexible syntax. I certainly appreciate the "special" (I think that's the right name) register syntax. It's not a big deal, but it offends me when I carefully code L R1,MYFOOVAL/SOMEMAC FOO=(1) and see that the macro has generated LR 1,1. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Friday, September 1, 2017 9:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEAARR I didn't really intend to make a big deal about this particular macro, but I did step in it by casting aspersions on it. Sorry for that... but I'll explain a bit more since you provided such a complete background. I think the DYNSTORAGE keyword is redundant, and the macro could select from either the direct (RX-type) or indirect (A-type) keywords for each of the four major address keywords individually, depending on what's specified. And really, whether I have "dynamic storage" available has nothing to do with how the parms should be passed. I don't have a problem with the *PTR keywords as options, although I see no need for them. If the address is in storage, then I can easily L/LG or whatever myself and pass it in a register. But most of the time, it's easier and more efficient to LA/LAY/LARL the addresses, if not already in a register. Now that's a problem if I'm prevented from using R14 R15, R0, and R1; it's common not to have a whole bunch of free registers. And it's more efficient to put the addresses where they need to be once, instead of copying them. For example, I know that the ARR address is going to wind up in general register 1; I have the entire instruction set available to get it in there, without needing help from the macro. Many existing macros work that way, and I've never seen a problem with it. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
