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