>>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
