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

Reply via email to