On 4 September 2017 at 21:40, Peter Relson <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN
