<snip> 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. </snip> Surely you understand that it is not possible in general for a macro to make such decisions.
<snip> 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. </snip> It is similarly impossible to know that it is OK to use LARL. And it is impossible to know that LAY is needed instead of LA. And it would be poor form to change to use a 6-byte instruction when a 4-byte instruction both had been used "forever" and works. <snip> 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. </snip> You only know what you know, which is what it does today. The macro might find a need to use register one for its own temporary purposes prior to priming it with the data that you have provided. That is far from uncommon. <snip> 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. </snip> I fully agree. The first is of course a nice thought but it won't happen. The point about level of indirection is of course critical. And yes it means reading the book (and more often means reading the expansion) to make sure what you got is what you wanted. <snip> 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. </snip> I'm not sure which macros those are, but IBM standards are clear on what is to be supported. They might be archaic, but they are standards. It's quite possible that those macros do not comply. 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
