I can see both points but , viewpoint/opinion has many facets. Experience, education, pre-conceived ideas, unrealistic expectations just to name a few. This is own opinion. If it works for you , great, if not look at other techniques or ask on here of some of the smartest ppl I know and respect.
Scott On Sat, Sep 2, 2017 at 11:29 AM Charles Mills <charl...@mcn.org> wrote: > > I'm not sure which macros those are > > The (S,scon) and (*,scon) formats are toward the bottom of the page here: > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.id > ad500/x9a.htm > <https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad500/x9a.htm> > > > I know that the ARR address is going to wind up in general register 1; > > I have the entire instruction set available to > ... > > You only know what you know, which is what it does today. > > This really comes down to a philosophical question of "what is the point of > a macro?" Obviously *EVERYTHING* a macro does could be done by a moderately > skilled assembler programmer in open code. > > In a way, the macros are for the convenience of IBM, not the convenience of > the user programmer. IBM could have documented that an associated recovery > routine was established by loading x into R1, pointing R0 at a block > containing blah-blah and calling the address at +X'234' off some pointer in > the CVT. (I'm making up those specific details.) IBM instead chose to > document (that is, make the supported API be) IEAARR > ARRPTR=arr,DYNSTORAGE=... In many ways the latter is easier, and as @Peter > points out, at least in theory more flexible for IBM going forward. (I say > in theory because while IBM documents at the macro level, there is often a > compatibility need to keep the expansions the same. If IBM had been willing > to say a DCB is a macro rather than a DCB is a storage block with a fixed > layout, the QSAM AMODE 24 issue would have been trivial to solve.) > > This will come as utter heresy to all of the long-time assembler (and PL/X) > jockeys on this list but after ten or so years where my primary z/OS > language has been C++ I have really come to appreciate the architectural > philosophy of the C library. There are no "system macros" in the sense we > know and love for MVS. EVERYTHING is a call using standard linkage. There > is > no STORAGE macro; there is address = malloc(bytes) and free(address). I > "get" all of the "efficiency" arguments for the bit-twiddling that macros > can do, but FWIW -- de gustibus non est disputandum -- I have come to like > the "standard library" approach much better. > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Peter Relson > Sent: Saturday, September 2, 2017 6:47 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: IEAARR > > <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" > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
