Re: IEAARR

[Peter Relson]

I think these two separated points from the same post are to some extent 
in
conflict. If the only documentation of an interface is the macro that
invokes it ...

I do not see a conflict..

I did not say that the macro is the documentation. I said that the book is 
the documentation.
The fact that mappings might be available for parameter lists often does 
not mean that that mapping is intended for you to use to build your own. 
For example, it might be intended for the macro to use and rely upon, or 
it might be provided for diagnostic reasons.

And the change for which I gave an example that would break misuse of an 
interface did not involve recompilation. But it was incompatible if you 
did not follow the documented rules. We do not, in general, ever expect to 
get the user community to recompile. And as a result you can be quite 
confident (in the absence of documentation to the contrary such as 
migration information about an incompatibility) that if you mimic the 
expansion exactly (by whatever mechanism you do so), you will have 
something that works and continues to work.

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

Re: IEAARR

[Rob Scott]

I would change that third sentence to :

"You can demand that your macro *is* the interface, but that implies you 
require your clients to re-assemble their code whenever they want to utilize 
any of the *real* interface changes"

Any interface worth its salt would support previously assembled code that is 
ignorant of the new parameter list bits and bytes.

Rob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Thursday, September 7, 2017 1:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEAARR

The crux of the matter is that an interface must be defined at the execution 
level.  Macros are ephemeral, merely a convenience. You can demand that your 
macro *is* the interface, but that implies you require your clients to 
re-assemble their code whenever the *real* interface changes.  Not so good from 
a customer-service (or
profit-making) perspective.

Some macros are more convenient for my purposes than others.  C'est la vie.

--
sas

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 877.328.2932
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEAARR

[Steve Smith]

The crux of the matter is that an interface must be defined at the
execution level.  Macros are ephemeral, merely a convenience. You can
demand that your macro *is* the interface, but that implies you
require your clients to re-assemble their code whenever the *real*
interface changes.  Not so good from a customer-service (or
profit-making) perspective.

Some macros are more convenient for my purposes than others.  C'est la vie.

-- 
sas

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEAARR

[Tony Harminc]

On 4 September 2017 at 21:40, Peter Relson  wrote:

>
> If you comply with the documented requirements of an interface then if you
> choose to "roll your own" rather than use the macro, you will survive.
> And you should expect that we will provide notification (as an
> incompatibility) if that does not hold for some reason (upon which
> notification you will be on the hook to see that notification and react).
>
...

> IBM definitely chooses to consider the book description of the macro to be
> the interface. If you use the macro, then you are intended to be protected
> from incompatible changes.
> If you do not, then you are on your own.
>

I think these two separated points from the same post are to some extent in
conflict. If the only documentation of an interface is the macro that
invokes it, then any "roll your own" approach is going to rely on "not PI"
descriptions of what goes on (such as the diagnosis books), on reading the
macro source, or on black-box reverse engineering what the macro generates,
Those are by definition potentially risky. It need not be this way. For
example, while RACF provides a quite fancy RACROUTE macro, the parameter
list it generates is also described by a mapping macro (well two actually,
both PI), and it is quite feasible to "roll your own" by generating the
list yourself. More commonly, it is easy and convenient to allow the macro
to generate the list based on assembly time information, and then to have
the program modify it based on information available only at run time. The
alternative is to code as many variations of the RACROUTE as may be needed,
and then branch to the desired one based on the run time information. I
have a module here that would require 24 different RACROUTEs to do this,
whereas I can easily do it with one in a much more readable and compact
manner using the above technique.

I don't believe there is a mapping macro for the parameter list for e.g.
STORAGE OBTAIN. Well, presumably there is one, but in PL/X and used only by
the code at the other end of the PC that is generated by the STORAGE macro.

As for incompatible changes to parameter lists, this must surely be very
rare, because IBM has famously supported upward compatibility "forever". A
program last assembled in 1969 on OS/MFT will generally still work on z/OS
2.3 today. Compatibility at the parameter list level is quite different
from e.g. the notion that a macro might one day start using R1 as a work
register. That is a quite legitimate change that shouldn't require
notification, or perhaps only as a courtesy or heads-up.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEAARR

[Steve Smith]

In-line responses this time, hopefully clearly marked after mail processing:

On Sat, Sep 2, 2017 at 9:46 AM, Peter Relson  wrote:
> 
> 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.
> 
> 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.

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

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

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

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

Re: IEAARR

[Charles Mills]

I doubt anyone is interested in a long dissertation on what I think. I will
just clarify two things.

- After reading what Peter writes about the benefits of macros, I think we
agree ...

- Yeah, comparing malloc() to STORAGE OBTAIN was a poor choice. malloc() is
like a baby GETMAIN with no options other than the size of the storage. My
point was not "number of features and variations" but rather "everything is
a standard call with standard linkage and parameters." Perhaps a better
comparison might be the __console2() library function, which manages to
implement many (most?) features of WTO, but do it in a standard call with
standard linkage.

Not sure of the exact definition of "system programming." Some use it to
mean SMP/E and SYS1.PARMLIB and some use the term to mean developing
software that does "sophisticated" functions, not reports and big files of
financial data. For the latter, I find C++ a terrific (system?) programming
language. I would guess that more "sophisticated" (whatever that means)
programs (across all platforms) are written in C/C++ than any other
language. Certainly true if you group in C++'s logical follow-on, Java. As I
wrote earlier, I am very happy to leave the "oh crap, I forgot to clear R2"
type problems of assembler behind me. And in a shout-out to IBM, I have been
*very* pleased with the performance of the compiled code.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Monday, September 4, 2017 6:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEAARR

My take is this:

If you comply with the documented requirements of an interface then if you
choose to "roll your own" rather than use the macro, you will survive.
And you should expect that we will provide notification (as an
incompatibility) if that does not hold for some reason (upon which
notification you will be on the hook to see that notification and react).

But that does mean that you have to start by complying (and that includes
obeying the register-choice limitations). If you choose not to comply,
whether you roll your own or not, and we change something that affects only
someone who does not comply, we might notify, we might not. The risk is
yours (and your customers') to bear. It is up to your customers (or you if
it's for yourself) to gauge whether that risk is acceptable or not. And if
you don't inform your customers of that risk, then they might be rather
unhappy if something unfriendly results that they can tie to that
occurrence.

Notification might include notification to ISVs in Partners in Development
(if I have that name right) as well as within APAR hold data and/or release
migration data depending on the delivery mechanism of the change.


in a way, macros are for the convenience of IBM, not the convenience of the
user programmer.

I'd say "not even close". They are clearly for the convenience of the user
as well as for the provider (whether that provider by IBM or anyone else). 

It is far easier to invoke a macro than code all the bits and bytes (as well
as getting whatever syntax checking the macro provides).
It is true that it is likely more convenient for the provider to describe
how to invoke the macro than how to build the parameter area. 
IBM definitely chooses to consider the book description of the macro to be
the interface. If you use the macro, then you are intended to be protected
from incompatible changes.
If you do not, then you are on your own.


DCB

We are talking here about executable macros, not macros that define control
blocks.


There is
no STORAGE macro; there is address = malloc(bytes) and free(address).

And that's one reason why C is a nice application programming language and
not so great as a z/OS system programming language. 
If all z/OS storage were one subpool, there wouldn't be a z/OS.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEAARR

[Peter Relson]

Clarifying:


If you comply with the documented requirements of an interface then if you 

choose to "roll your own" rather than use the macro, you will survive.


By "roll your own" I meant that you produce exactly what the macro 
produces in terms of what gets passed to the service and what (and how) 
output data is dealt with.
So usually you would invoke the macro, see what it expands to, then (in 
effect) copy that.

And of course that does also imply that you "got it right" whether by the 
macro or the hand-built analog.

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

Re: IEAARR

[Peter Relson]

My take is this:

If you comply with the documented requirements of an interface then if you 
choose to "roll your own" rather than use the macro, you will survive.
And you should expect that we will provide notification (as an 
incompatibility) if that does not hold for some reason (upon which 
notification you will be on the hook to see that notification and react).

But that does mean that you have to start by complying (and that includes 
obeying the register-choice limitations). If you choose not to comply, 
whether you roll your own or not, and we change something that affects 
only someone who does not comply, we might notify, we might not. The risk 
is yours (and your customers') to bear. It is up to your customers (or you 
if it's for yourself) to gauge whether that risk is acceptable or not. And 
if you don't inform your customers of that risk, then they might be rather 
unhappy if something unfriendly results that they can tie to that 
occurrence.

Notification might include notification to ISVs in Partners in Development 
(if I have that name right) as well as within APAR hold data and/or 
release migration data depending on the delivery mechanism of the change.


in a way, macros are for the convenience of IBM, not the convenience of
the user programmer.

I'd say "not even close". They are clearly for the convenience of the user 
as well as for the provider (whether that provider by IBM or anyone else). 

It is far easier to invoke a macro than code all the bits and bytes (as 
well as getting whatever syntax checking the macro provides).
It is true that it is likely more convenient for the provider to describe 
how to invoke the macro than how to build the parameter area. 
IBM definitely chooses to consider the book description of the macro to be 
the interface. If you use the macro, then you are intended to be protected 
from incompatible changes.
If you do not, then you are on your own.


DCB

We are talking here about executable macros, not macros that define 
control blocks.


There is
no STORAGE macro; there is address = malloc(bytes) and free(address).

And that's one reason why C is a nice application programming language and 
not so great as a z/OS system programming language. 
If all z/OS storage were one subpool, there wouldn't be a z/OS.

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

Re: IEAARR

[scott Ford]

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

Re: IEAARR

[Charles Mills]

> 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


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

Re: IEAARR

[Peter Relson]

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.

Surely you understand that it is not possible in general for a macro to 
make such decisions. 


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.

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.


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.

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.


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.

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.


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.

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

Re: IEAARR

[Charles Mills]

It ain't gonna happen, of course, but 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.

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.

I certainly appreciate the "special" (I think that's the right name) register 
syntax. It's not a big deal, but it offends me when I carefully code L 
R1,MYFOOVAL/SOMEMAC FOO=(1) and see that the macro has generated LR 1,1.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Friday, September 1, 2017 9:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEAARR

I didn't really intend to make a big deal about this particular macro, but I 
did step in it by casting aspersions on it.  Sorry for that...
but I'll explain a bit more since you provided such a complete background.

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.

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.

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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEAARR

[Steve Smith]

I didn't really intend to make a big deal about this particular macro,
but I did step in it by casting aspersions on it.  Sorry for that...
but I'll explain a bit more since you provided such a complete
background.

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.

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.

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.

Anyway, my point of view.  While I've rather over-explained some
details for completeness, I'm well aware that *you* (and most readers
here) know all this.  It's not intended to insult your intelligence
:-)

sas


On Fri, Sep 1, 2017 at 10:58 AM, Peter Relson  wrote:
>>>Also, IEAARR is an 1887-line monstrosity that looks unmaintainable to
> me... but that's not my problem.
>>
>>Macro code looks "generated" to me - I doubt whether it is maintained in
> this specific source form.
>
> Rob's "doubt" is confirmed. It is very easily maintainable.  Many macros
> are much much larger.
>
>>First, DYNSTORAGE=NOTAVAIL | AVAIL
>>
>>Two complete mutually-exclusive sets of keywords; and the ones used have
> to match the above (ridiculous) keyword.  No mixing of storage and
> register >operands is allowed.  All keywords are either required or
> forbidden.
>
> I'm sorry that you don't like my choice of "DYNSTORAGE" or NOTAVAIL/AVAIL.
>  The point is that if you have dynamic storage available you have the
> flexibility to do things like putting operands into storage and having the
> expansion "L" the operand.  If you do not have dynamic storage available,
> you must live with "LA" (for which you need addressability to the thing
> for which the address is being taken).
> Surely you are aware that macro syntax historically allows only two
> flavors -- specification surrounded by parens indicating "something is in
> a register" and specification not surrounded by parens. That does not give
> you the four choices that would be nicest-- get the value from the reg,
> get the value located by the address in the reg, use "LA" on the operand,
> use "L" (or perhaps "LG") on the operand. Very few macros give you all 4
> choices. In fact the original IEAARR only gave you the 2nd and 4th
> choices.
>
> Why would anyone care when there are a lot of keywords? You use what
> applies to your need. The keywords (e.g., ARR vs ARRPTR) differ in what
> you can specify which is what provides the flexibility that most macros do
> not provide.  I would say that there *is* the capability of "mixing of
> storage and register operands" but I can see that there is not the
> capability of "give me all 4 choices for every keyword" on any given
> invocation. I don't recall why I went the route I did. I presume it was
> because I was trying to solve a need that I had, since no one had ever
> asked for that additional functionality, and it met my need and I found it
> easier to do it this way than the other. If there was a justified
> requirement for providing the flexibility of "all 4 for every" we could
> consider it. I'd imagine that it would be hard to justify (but not overly
> hard to implement).
>
>>But, it specifically prevents the user from specifying register 1 (for
> example) with its operand.
> As is the case for 99% of macro keyword operands in z/OS.
>
>>(I can trick it by using 'ARR=R1', so it just generates LR 1,R1).
> Sure you can "trick it". There are myriad ways to trick things across the
> set of interfaces that z/OS provides if you want your clients to have the
> risk that results from your not obeying the requirements of an interface.
> The fact that it works today does not mean that it is supported or will
> necessarily work tomorrow (although I doubt very much that this particular
> macro would change in a way that would make your "trick" stop working).
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the 

Re: IEAARR

[Peter Relson]

>>Also, IEAARR is an 1887-line monstrosity that looks unmaintainable to 
me... but that's not my problem.
>
>Macro code looks "generated" to me - I doubt whether it is maintained in 
this specific source form.

Rob's "doubt" is confirmed. It is very easily maintainable.  Many macros 
are much much larger. 

>First, DYNSTORAGE=NOTAVAIL | AVAIL
>
>Two complete mutually-exclusive sets of keywords; and the ones used have 
to match the above (ridiculous) keyword.  No mixing of storage and 
register >operands is allowed.  All keywords are either required or 
forbidden.

I'm sorry that you don't like my choice of "DYNSTORAGE" or NOTAVAIL/AVAIL. 
 The point is that if you have dynamic storage available you have the 
flexibility to do things like putting operands into storage and having the 
expansion "L" the operand.  If you do not have dynamic storage available, 
you must live with "LA" (for which you need addressability to the thing 
for which the address is being taken).
Surely you are aware that macro syntax historically allows only two 
flavors -- specification surrounded by parens indicating "something is in 
a register" and specification not surrounded by parens. That does not give 
you the four choices that would be nicest-- get the value from the reg, 
get the value located by the address in the reg, use "LA" on the operand, 
use "L" (or perhaps "LG") on the operand. Very few macros give you all 4 
choices. In fact the original IEAARR only gave you the 2nd and 4th 
choices.

Why would anyone care when there are a lot of keywords? You use what 
applies to your need. The keywords (e.g., ARR vs ARRPTR) differ in what 
you can specify which is what provides the flexibility that most macros do 
not provide.  I would say that there *is* the capability of "mixing of 
storage and register operands" but I can see that there is not the 
capability of "give me all 4 choices for every keyword" on any given 
invocation. I don't recall why I went the route I did. I presume it was 
because I was trying to solve a need that I had, since no one had ever 
asked for that additional functionality, and it met my need and I found it 
easier to do it this way than the other. If there was a justified 
requirement for providing the flexibility of "all 4 for every" we could 
consider it. I'd imagine that it would be hard to justify (but not overly 
hard to implement).

>But, it specifically prevents the user from specifying register 1 (for 
example) with its operand. 
As is the case for 99% of macro keyword operands in z/OS. 

>(I can trick it by using 'ARR=R1', so it just generates LR 1,R1).
Sure you can "trick it". There are myriad ways to trick things across the 
set of interfaces that z/OS provides if you want your clients to have the 
risk that results from your not obeying the requirements of an interface. 
The fact that it works today does not mean that it is supported or will 
necessarily work tomorrow (although I doubt very much that this particular 
macro would change in a way that would make your "trick" stop working).

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

Re: IEAARR

[Rob Scott]

>> Also, IEAARR is an 1887-line monstrosity that looks unmaintainable to me... 
>> but that's not my problem.

Macro code looks "generated" to me - I doubt whether it is maintained in this 
specific source form.

Rob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Wednesday, August 30, 2017 4:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEAARR

First, DYNSTORAGE=NOTAVAIL | AVAIL

Two complete mutually-exclusive sets of keywords; and the ones used have to 
match the above (ridiculous) keyword.  No mixing of storage and register 
operands is allowed.  All keywords are either required or forbidden.

The expansion clearly shows what operands are loaded into which registers.  
But, it specifically prevents the user from specifying register 1 (for example) 
with its operand.  (I can trick it by using 'ARR=R1', so it just generates LR 
1,R1).

Also, IEAARR is an 1887-line monstrosity that looks unmaintainable to me... but 
that's not my problem.

sas

On Wed, Aug 30, 2017 at 9:32 AM, Peter Relson <rel...@us.ibm.com> wrote:
>>The IEAARR macro itself is ridiculous.
>
> OK, I'll bite. In what way(s)?
>
> 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



--
sas

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 877.328.2932
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEAARR

[Steve Smith]

First, DYNSTORAGE=NOTAVAIL | AVAIL

Two complete mutually-exclusive sets of keywords; and the ones used
have to match the above (ridiculous) keyword.  No mixing of storage
and register operands is allowed.  All keywords are either required or
forbidden.

The expansion clearly shows what operands are loaded into which
registers.  But, it specifically prevents the user from specifying
register 1 (for example) with its operand.  (I can trick it by using
'ARR=R1', so it just generates LR 1,R1).

Also, IEAARR is an 1887-line monstrosity that looks unmaintainable to
me... but that's not my problem.

sas

On Wed, Aug 30, 2017 at 9:32 AM, Peter Relson  wrote:
>>The IEAARR macro itself is ridiculous.
>
> OK, I'll bite. In what way(s)?
>
> 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



-- 
sas

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN