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