Discussion:
IEAARR
Add Reply
Steve Smith
2017-08-30 15:48:09 UTC
Reply
Permalink
Raw Message
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
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,
--
sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Rob Scott
2017-08-31 07:54:34 UTC
Reply
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On Behalf Of Steve Smith
Sent: Wednesday, August 30, 2017 4:49 PM
To: IBM-***@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
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
--
sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-09-01 14:57:35 UTC
Reply
Permalink
Raw Message
Post by Rob Scott
Post by Steve Smith
Also, IEAARR is an 1887-line monstrosity that looks unmaintainable to
me... but that's not my problem.
Post by Rob Scott
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.
Post by Rob Scott
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).
Post by Rob Scott
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.
Post by Rob Scott
(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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2017-09-01 16:27:20 UTC
Reply
Permalink
Raw Message
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
Post by Steve Smith
Post by Rob Scott
Post by Steve Smith
Also, IEAARR is an 1887-line monstrosity that looks unmaintainable to
me... but that's not my problem.
Post by Rob Scott
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.
Post by Rob Scott
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).
Post by Rob Scott
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.
Post by Rob Scott
(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,
--
sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-09-01 16:49:32 UTC
Reply
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On Behalf Of Steve Smith
Sent: Friday, September 1, 2017 9:28 AM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-09-02 13:45:42 UTC
Reply
Permalink
Raw Message
<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.

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

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

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

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

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-09-02 15:28:16 UTC
Reply
Permalink
Raw Message
Post by Peter Relson
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
Post by Peter Relson
I know that the ARR address is going to wind up in general register 1;
I have the entire instruction set available to
...
Post by Peter Relson
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-***@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Saturday, September 2, 2017 6:47 AM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
scott Ford
2017-09-02 16:42:49 UTC
Reply
Permalink
Raw Message
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
Post by Charles Mills
Post by Peter Relson
I'm not sure which macros those are
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>
Post by Peter Relson
I know that the ARR address is going to wind up in general register 1;
I have the entire instruction set available to
...
Post by Peter Relson
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
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-----
Behalf Of Peter Relson
Sent: Saturday, September 2, 2017 6:47 AM
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,
--
Scott Ford
IDMWORKS
z/OS Development

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2017-09-05 20:54:11 UTC
Reply
Permalink
Raw Message
Post by Peter Relson
<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.
Post by Peter Relson
<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.
Post by Peter Relson
<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?
Post by Peter Relson
<snip>
what would be really nice would be if every macro had a consistent way of
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.
Post by Peter Relson
<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.
Post by Peter Relson
Peter Relson
z/OS Core Technology Design
--
sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-09-05 01:39:21 UTC
Reply
Permalink
Raw Message
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.

<snip>
in a way, macros are for the convenience of IBM, not the convenience of
the user programmer.
</snip>
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.

<snip>
DCB
</snip>
We are talking here about executable macros, not macros that define
control blocks.

<snip>
There is
no STORAGE macro; there is address = malloc(bytes) and free(address).
</snip>
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-09-05 15:17:53 UTC
Reply
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Monday, September 4, 2017 6:40 PM
To: IBM-***@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.

<snip>
in a way, macros are for the convenience of IBM, not the convenience of the
user programmer.
</snip>
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.

<snip>
DCB
</snip>
We are talking here about executable macros, not macros that define control
blocks.

<snip>
There is
no STORAGE macro; there is address = malloc(bytes) and free(address).
</snip>
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Harminc
2017-09-06 17:20:28 UTC
Reply
Permalink
Raw Message
Post by Peter Relson
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).
...
Post by Peter Relson
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2017-09-07 00:09:27 UTC
Reply
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Rob Scott
2017-09-07 09:41:05 UTC
Reply
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On Behalf Of Steve Smith
Sent: Thursday, September 7, 2017 1:11 AM
To: IBM-***@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 ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-09-05 14:11:37 UTC
Reply
Permalink
Raw Message
Clarifying:

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

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-09-07 12:37:34 UTC
Reply
Permalink
Raw Message
<snip>
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 ...
</snip>
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...