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. <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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
