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
- 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
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.
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Monday, September 4, 2017 6:40 PM
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
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
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.
We are talking here about executable macros, not macros that define control
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN