Charles Sorry - a rather late response.
As you may know I normally restrict myself to questions relating to the two Communications Server components but I have messed about with trivial assembler programs which were completely my own and with no expectation that anyone will ever need to maintain them except myself - but possibly at some indefinite time in the future. So having got that caveat out of the way, I am about to pronounce what to some might be heresy. So any reading this who are of a nervous or excitable disposition should be sitting down and keeping clear of sharp objects and may care to have a sedative handy preferably in a soft plastic beaker. 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 came to this conclusion a long time ago as soon as the obvious point came home that the logic the "other side", as it were, of the SVC call which was going to be using the register values and any "control block" associated with the SVC call wouldn't have the first clue regarding whether macros had loaded the register values and created the "control block" or rawly coded instructions had. The only remaining matter is "maintainability". That is why I suggest you redouble your undoubtedly normal sterling efforts to provide superb commenting around the instructions surrounding the SVC call. Actually I first came to these conclusions not so much with SVC calls but with the BALR 14,15 calls associated with the VTAM API and it was all about flexibility. I used to code up my trivial VTAM programs with a timorous mix of macro instructions and operands where I could and raw instructions dipping into the "control blocks" where I absolutely couldn't. Then on one famous occasion - for me anyhow! - I tried to use the interface which was actually supposed to get around this little difficulty, the xxxCB macros[2]. Getting on for some 10 years before when I had attended a VTAM class at a time when there was so little to VTAM systems programming that the course also included application programming, I learned just a little about these xxxCB macros and how they were supposed to work and also that, since the similarly named and abbreviated VTAM and VSAM were developed at about the same time and there was a fond hope that the similarity in structure provided a synergy which could assist programmers in moving data from the VTAM API to the VSAM API and back again.[3] These xxxCB calls also happen (ed) to be part of both the VTAM and the VSAM API. My attempt to use the VTAM xxxCB macros in place or raw instructions peeking into and zapping fields in "control blocks" failed miserably. Both (a) they didn't seem to have kept up with all the changes to the "control block" fields and (b) once you got to see how they worked it was evident you were just adding yet another "control block", the one used by the xxxCB macro to the "control block" with which you really wanted to work. What a mess! It began to look as if these xxxCB macros were the result of an instruction from a "suit" of whom the poor developer was too afraid to be able to point out that the whole idea was nonsense. By pure chance I happen to be in contact just this week concerning another technical exchange - a Techdoc or two no less - with a then colleague who is a vital part of this story. Having discovered that the VTAM xxxCB macros were deficient in their capabilities, I mentioned this to him and what I was trying to do. He "took me aside", as it were, and confided that, actually the xxxCB macros had been abandoned a few releases - maybe an odd version - before! This was sometime in the early '80s.[4] The moral of this story is that there is no substitute for using raw instructions in order to take a look inside "control blocks" and fit them up for the purpose you have in mind. You can use "L" form of macros if you like or you can just build the "control block" "by hand". You can use "E" form of macros if you like or you can just load the registers and issue the SVC or whatever is currently the most popular flavour of the archetypical BALR 14,15, whichever call the macro is "disguising". After all, when it comes to trying to work out if the call or SVC did what it was supposed to do, you tend to be using raw instructions - although I tried for a while using table-driven common logic for the analysis of "call" results with limited success. Chris Mason [1] I also discovered that the storage efficiency of the code generated by the macro expansion left something to be desired - but it's important to know that this opinion is given by someone who was present when a bright attendee to a talk on how a 4K - yes "K" - spooling package for DOS/360 had been put together back in 1968 or so could benefit from using an AR instruction operation code as a packed decimal 1! It's a "mind-set" from which it is impossible to escape! [2] GENCB, MODCB, SHOWCB and TESTCB. [3] If anyone can provide evidence that any programs which actually did manage to exploit this similarity in structure, please come forward! [4] Whether or not this applies to the *VSAM* xxxCB macros I couldn't say. On Tue, 2 Nov 2010 14:33:31 -0400, Charles Mills <[email protected]> wrote: >Thanks. Yes. Agree with all of your points. > >I am using identical (in so far as the macro allows!) parms on both the E >and the L macros (per the example I referenced). > >I am not trying to do a "one-shot" multi-line WTO for the reason you >described. What a goofy design! It is perfect for someone with "n" >hard-coded messages but how likely is that in the real world? I don't even >know what my "n" is ahead of time. I am doing "n" one-line WTO's followed by >an "E" type WTO. > >Charles > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf >Of Chris Craddock >Sent: Tuesday, November 02, 2010 12:52 PM >To: [email protected] >Subject: Re: WTO ABEND D23 help > >> I see that after tweaking you got it working. One tip for the future. If >> you are going to use parms like CART and CONSID in the MF=E, they should >> also be used in the MF=L. Some parm lists have flags set in the MF=L >> indicating what parms are being supplied. If you fill them in via MF=E, >> there can be problems if those parms (and thus the flags) are not also in >> the MF=L. I am not saying that that this was your problem but it does not >> hurt to make sure by having the parm in both macros (if not needed, it >will >> not cause any problems for macros where the MF=L just provides the parm >area >> but no content and the MF=E does ALL the work of building the parms). >> > > >that's true. It is best to use as close to identical MF=E and MF=L >expansions as possible. That can be a bit tricky if you don't know ahead of >time how many message lines you're going to need. The limit for a >non-privileged caller is 10 btw. I also feel honor bound to point out that >the IEZWPL mapping is (to be charitable) extremely misleading. If you're >going to build your own expansion you will need to study the actual WTO >macro expansion rather than relying on IEZWPL. Try "WTO TEXT=(...) with one, >then two and then three message lines and you will fairly quickly get the >gist of it. ---------------------------------------------------------------------- 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
