Re: IEAARR
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 ... 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEAARR
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Thursday, September 7, 2017 1:11 AM To: IBM-MAIN@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 lists...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEAARR
On 4 September 2017 at 21:40, Peter Relson 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEAARR
In-line responses this time, hopefully clearly marked after mail processing: On Sat, Sep 2, 2017 at 9:46 AM, Peter Relson wrote: > > 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. > > 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. > > 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. > > 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. > > 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. > > 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? > > 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. > > 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. > > 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'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. > > Peter Relson > z/OS Core Technology Design > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEAARR
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. in a way, macros are for the convenience of IBM, not the convenience of the user programmer. 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. DCB We are talking here about executable macros, not macros that define control blocks. There is 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEAARR
Clarifying: 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. 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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. in a way, macros are for the convenience of IBM, not the convenience of the user programmer. 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. DCB We are talking here about executable macros, not macros that define control blocks. There is 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. 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
Re: IEAARR
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 On Sat, Sep 2, 2017 at 11:29 AM Charles Mills wrote: > > 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 > <https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad500/x9a.htm> > > > I know that the ARR address is going to wind up in general register 1; > > I have the entire instruction set available to > ... > > 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-MAIN@LISTSERV.UA.EDU] On > Behalf Of Peter Relson > Sent: Saturday, September 2, 2017 6:47 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: IEAARR > > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEAARR
> 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 > I know that the ARR address is going to wind up in general register 1; > I have the entire instruction set available to ... > 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-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Saturday, September 2, 2017 6:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEAARR 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEAARR
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. Surely you understand that it is not possible in general for a macro to make such decisions. 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. 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. 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. 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. 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. 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. 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'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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEAARR
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Friday, September 1, 2017 9:28 AM To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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. 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 On Fri, Sep 1, 2017 at 10:58 AM, Peter Relson wrote: >>>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's "doubt" is confirmed. It is very easily maintainable. Many macros > are much much larger. > >>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). > >>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. > >>(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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEAARR
>>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's "doubt" is confirmed. It is very easily maintainable. Many macros are much much larger. >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). >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. >(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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEAARR
>> 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-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Wednesday, August 30, 2017 4:49 PM To: IBM-MAIN@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 On Wed, Aug 30, 2017 at 9:32 AM, Peter Relson wrote: >>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 > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 On Wed, Aug 30, 2017 at 9:32 AM, Peter Relson wrote: >>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 email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN