Chris > I think you have missed the point I was making about the WTO interface. I do NOT advocate ditching formal interfaces in general.
Well, you thought wrong! It's very clear to me and I would expect to the vast majority of readers that what I said >> I feel prompted to suggest a step further than the course proposed by Chris Craddock. with some emphasis on the use of the word "further" in case you in turn missed a point, indicates clearly that I did ***not*** miss your point. I gather (ed) that you favoured retaining the macro in the source code - I assume that's what you mean by "formal interface" - and obviously - well, again I'd have thought - I favour retaining the actual interface there being no choice after all. My point was - and I'll repeat it for your benefit at least - that, having taken the trouble to examine what precisely the actual interface was by looking at what goes on "under the covers" of the macro >>> ... you will need to study the actual WTO macro expansion ... possibly, as appeared to be Charles's need, because an operand value or two or more needed to be set dynamically, you may as well not bother with using the macro at all, the prime example I recall being struggling to get all the right brackets in the right place for something like WTO MF=(E,(1)) why not simply code SVC WTO and place an entry in the EQU list at the end of the source file WTO EQU 35 What is the advantage of not actually having the macro in the source code?: Full flexibility in the use of the actual interface. What is the disadvantage of not actually having the macro in the source code?: Not having as unambiguous documentation of how the actual interface was used as, in principle, ought to be evident from the possibly tortuous macro statement character string. It's because of this potential disadvantage that I emphasised comments which could compensate. Is there any impact whatsoever in having or in not having the macro in the source code on the reliability of the generated logic?: Of course not - but it's here that the timorous might allow themselves to be influenced by the FUD factor. > Doing it "by hand" is error prone ... Once it executes correctly, you will have eliminated any possible errors relating to the coding "by hand". That's a ridiculous objection fitting firmly in the FUD category! Because I have to be so precise given your ability to misconstrue, I do not suggest that there might not still be errors but that those errors are likely to be the same as a programmer might introduce if still using the macro. > ... and certainly not worth the effort if you have to do it more than once. As Charles has already pointed out - and quite rightly bitten the head off the person who suggested it - it is very likely that the logic appears only once (in a subroutine) *if* extensive use is being made of the available operand parameters with a need to set them dynamically. If it makes for a neater program module that the macro appears just a few times with static operand values, by all means use the macros - although I would tend not to mix using macros and not using macros simply as a matter of aesthetics - a concept which I guess has its place in assembler coding! > I would probably concede your point about the xxxCB macros too, although I've seen the VSAM versions used extensively in products I've been associated with and once you get the gist of them they aren't that onerous. I'm not clear what point you have conceded here. It's not that I found them too difficult to use. Rather I discovered a) they are pointless because what they pretend to achieve - not having to "dip" into typically the RPL control block - they do not, given that you are just as likely to need to dip into the control block associated with the xxxCB macro, b) in the case of VTAM, they were abandoned sometime between the birth of VTAM and the mid 1980s. Incidentally, I checked in the z/OS Communications Server SNA Programming manual Chapter 8, "Setting and testing control blocks and macro global variables": <quote> Setting and testing control block values - Control block values can be set by: -- Defining them in an ACB, EXLST, NIB, or RPL macroinstruction -- Specifying values in operands of RPL-based macroinstructions -- Using the manipulative macroinstructions GENCB and MODCB for certain fields -- Using the INQUIRE OPTCD=TERMS macroinstruction to generate an NIB or list of NIBs -- Using the DSECT-creating macroinstructions and assembler instructions to move values into specified fields. - Control block values can be tested by: -- Using the manipulative macroinstructions TESTCB and SHOWCB for certain fields -- Using the DSECT-creating macroinstructions and assembler instructions to test values in specified fields. </quote> Presumably, either at the time or after knuckles had been rapped, the abandonment of the xxxCB macros was indicated by the sly addition of the "for certain fields" text in the above! After a certain amount of digging around *for* and then *in* VSAM manuals, finally discovering "z/OS DFSMS Using Data Sets", I found no comparable text for VSAM so perhaps these macros have not been abandoned for VSAM. > ... I generally use the official macro interface under the covers unless > there is a compelling reason not to. Well, the Pope has just given in on a fundamental point where he - necessarily "he" unless in the future another such fundamental point is conceded - can never go back. If it's possible in one case, why not in others? The cat is out of the bag! Chris Mason On Fri, 19 Nov 2010 14:52:04 -0600, Chris Craddock <[email protected]> wrote: >On Fri, Nov 19, 2010 at 10:40 AM, Chris Mason <[email protected]>wrote: > >> Charles >> >> <snip>It was because of your earlier posts on automation topics that I >> bothered to >> poke my nose in here and it was only when I saw what might be a bit of >> irritation with the static nature of macro coding, even the "E" and "L" - >> or >> perhaps especially because of the "E" and "L" form - that I feel prompted >> to >> suggest a step further than the course proposed by Chris Craddock. >> >> This step is, having studied the "E" and "L" forms of the macro, ditch the >> pesky things and just code what is necessary in raw - but superbly >> documented as always, of course - instructions - with perhaps a comment box >> surrounding something like the macro text that you would have coded had it >> been dynamic enough.[1] >> > > >I think you have missed the point I was making about the WTO interface. I do >NOT advocate ditching formal interfaces in general. In fact, the exact >opposite is true. I generally advocate for using the official macro >interfaces for calling system services. Doing it "by hand" is error prone >and certainly not worth the effort if you have to do it more than >once. However there are a few egregious cases where the official interface >is (a) so old and crufty that it is unreasonably difficult to use for the >general case - the WTO interface we were discussing is a classic example, or >(b) is so complicated that it is essentially unusable by mere mortals - many >of the XES and LOGR interfaces would fall into that category. I would >probably concede your point about the xxxCB macros too, although I've seen >the VSAM versions used extensively in products I've been associated with and >once you get the gist of them they aren't that onerous. > >In those "too hard for mere mortals" cases I provide additional macro >infrastructure or kinder-gentler callable service interfaces so that other >developers don't have to wrestle with the ugly use cases. But even in those >cases I generally use the official macro interface under the covers unless >there is a compelling reason not to. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
