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. Anyway, my point of view. While I've rather over-explained some details for completeness, I'm well aware that *you* (and most readers here) know all this. It's not intended to insult your intelligence :-) sas On Fri, Sep 1, 2017 at 10:58 AM, Peter Relson <rel...@us.ibm.com> wrote: >>>Also, IEAARR is an 1887-line monstrosity that looks unmaintainable to > me... but that's not my problem. >> >>Macro code looks "generated" to me - I doubt whether it is maintained in > this specific source form. > > Rob's "doubt" is confirmed. It is very easily maintainable. Many macros > are much much larger. > >>First, DYNSTORAGE=NOTAVAIL | AVAIL >> >>Two complete mutually-exclusive sets of keywords; and the ones used have > to match the above (ridiculous) keyword. No mixing of storage and > register >operands is allowed. All keywords are either required or > forbidden. > > I'm sorry that you don't like my choice of "DYNSTORAGE" or NOTAVAIL/AVAIL. > The point is that if you have dynamic storage available you have the > flexibility to do things like putting operands into storage and having the > expansion "L" the operand. If you do not have dynamic storage available, > you must live with "LA" (for which you need addressability to the thing > for which the address is being taken). > Surely you are aware that macro syntax historically allows only two > flavors -- specification surrounded by parens indicating "something is in > a register" and specification not surrounded by parens. That does not give > you the four choices that would be nicest-- get the value from the reg, > get the value located by the address in the reg, use "LA" on the operand, > use "L" (or perhaps "LG") on the operand. Very few macros give you all 4 > choices. In fact the original IEAARR only gave you the 2nd and 4th > choices. > > Why would anyone care when there are a lot of keywords? You use what > applies to your need. The keywords (e.g., ARR vs ARRPTR) differ in what > you can specify which is what provides the flexibility that most macros do > not provide. I would say that there *is* the capability of "mixing of > storage and register operands" but I can see that there is not the > capability of "give me all 4 choices for every keyword" on any given > invocation. I don't recall why I went the route I did. I presume it was > because I was trying to solve a need that I had, since no one had ever > asked for that additional functionality, and it met my need and I found it > easier to do it this way than the other. If there was a justified > requirement for providing the flexibility of "all 4 for every" we could > consider it. I'd imagine that it would be hard to justify (but not overly > hard to implement). > >>But, it specifically prevents the user from specifying register 1 (for > example) with its operand. > As is the case for 99% of macro keyword operands in z/OS. > >>(I can trick it by using 'ARR=R1', so it just generates LR 1,R1). > Sure you can "trick it". There are myriad ways to trick things across the > set of interfaces that z/OS provides if you want your clients to have the > risk that results from your not obeying the requirements of an interface. > The fact that it works today does not mean that it is supported or will > necessarily work tomorrow (although I doubt very much that this particular > macro would change in a way that would make your "trick" stop working). > > Peter Relson > z/OS Core Technology Design > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- sas ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
