In-line responses this time, hopefully clearly marked after mail processing:
On Sat, Sep 2, 2017 at 9:46 AM, Peter Relson <rel...@us.ibm.com> wrote: > <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. > Not sure what we're missing here. The macro can easily determine whether ARR= or ARRPTR= was specified. And hell, write an error if both or neither are. What's not possible about that? And clearly, it would be far more useful to allow some operands to be direct, and some as indirect. > <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. > Part of my point. There are too many ways to address things nowadays... no macro can reasonably be expected to support them all. I don't want macros to support them all. I want it to let me load the register myself. > <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. > Sure you could change the macro, and/or change the actual interface. But IBM has a long history of never doing that. Any program assembled and running correctly in 1966 should still work, right? > <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. > Sometimes I think that going with callable services that use a standard parameter list is the safest way to go. But that certainly has its own issues. > <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. The VSAM xxxCB macros came from a strange time & place. Fortunately, they're completely unnecessary, although much of this discussion applies to them. > > Peter Relson > z/OS Core Technology Design > -- sas ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
