Re: IEATDUMP MF=L Can someone explain this?
I'm so use to splitting the name after the 3rd character I did not even notice this, until one of our younger programmers pronounced it as "I EAT DUMP" Robert Ngan HCL Technologies -Original Message- From: IBM Mainframe Assembler List On Behalf Of Jim Mulder Sent: Sunday, August 26, 2018 00:19 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEATDUMP MF=L Can someone explain this? I suppose the way one groups the letters would be influenced by one's own habits. I would expect that experienced z/OS programmers would know that for the past few decades, new macro names follow the same convention as module names and message IDs by starting with the 3 character prefix of the owning component. IEA - component prefix T- Transaction DUMP - Dump Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > From: "Paul Gilmartin" > <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 08/26/2018 01:07 AM > Subject: Re: IEATDUMP MF=L Can someone explain this? > Sent by: "IBM Mainframe Assembler List" > Who thinks up these macro names, anyway? That one wouldn't pass > muster as a California vanity license plate. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
Re: IEATDUMP MF=L Can someone explain this?
Bytes are cheap. (30-40 bytes anyway. ) Programmer time is expensive. Bugs are very expensive. I may just keep doing it the way I have been. CharlesSent from a mobile; please excuse the brevity. Original message From: Steve Smith Date: 8/27/18 12:04 PM (GMT-05:00) To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEATDUMP MF=L Can someone explain this? Me too. But remember, This is for NEW macros, the ones whose MF=E forms start with something like XC 88(,1),0(1), and use MF=(L,xxx). The older ones, that often have required data in the MF=L form, still have to be copied first. Typically you would put those MF=L in static storage, and define a working area DS XL(parml) to copy it into. I've overlaid a dozen of both types on each other in a case or two. Look at the expansions, and verify you didn't make incorrect assumptions. sas On 8/27/2018 11:18, Ed Jaffe wrote: > On 8/27/2018 4:45 AM, Charles Mills wrote: >>> Consider using the same list area for multiple services >> Is that documented anywhere? >> >> In other words, you are saying -- just to pick three macros that come to >> mind -- I could issue an ATTACHX, an EXTRACT and a CLOSE and use the >> same >> MF=L area for all (assuming the re-sue considerations you list)? > > I've been doing that since Old Man Noah cornered the market on gopher > wood! > > MyDSECT DSECT , > MacParm DS 0D > MACRO1 MF=L > ORG MacParm > MACRO2 MF=L > ORG MacParm > MACRO3 MF=L > ORG , > DS 0D > . > . (other stuff in MyDSECT) > . > > MyPgm RSECT , > . > MACRO1 MF=(E,MacParm) > . > MACRO2 MF=(E,MacParm) > . > MACRO3 MF=(E,MacParm) > . > . (etc) > . >
Re: IEATDUMP MF=L Can someone explain this?
Me too. But remember, This is for NEW macros, the ones whose MF=E forms start with something like XC 88(,1),0(1), and use MF=(L,xxx). The older ones, that often have required data in the MF=L form, still have to be copied first. Typically you would put those MF=L in static storage, and define a working area DS XL(parml) to copy it into. I've overlaid a dozen of both types on each other in a case or two. Look at the expansions, and verify you didn't make incorrect assumptions. sas On 8/27/2018 11:18, Ed Jaffe wrote: On 8/27/2018 4:45 AM, Charles Mills wrote: Consider using the same list area for multiple services Is that documented anywhere? In other words, you are saying -- just to pick three macros that come to mind -- I could issue an ATTACHX, an EXTRACT and a CLOSE and use the same MF=L area for all (assuming the re-sue considerations you list)? I've been doing that since Old Man Noah cornered the market on gopher wood! MyDSECT DSECT , MacParm DS 0D MACRO1 MF=L ORG MacParm MACRO2 MF=L ORG MacParm MACRO3 MF=L ORG , DS 0D . . (other stuff in MyDSECT) . MyPgm RSECT , . MACRO1 MF=(E,MacParm) . MACRO2 MF=(E,MacParm) . MACRO3 MF=(E,MacParm) . . (etc) .
Re: IEATDUMP MF=L Can someone explain this?
On 8/27/2018 4:45 AM, Charles Mills wrote: Consider using the same list area for multiple services Is that documented anywhere? In other words, you are saying -- just to pick three macros that come to mind -- I could issue an ATTACHX, an EXTRACT and a CLOSE and use the same MF=L area for all (assuming the re-sue considerations you list)? I've been doing that since Old Man Noah cornered the market on gopher wood! MyDSECT DSECT , MacParm DS 0D MACRO1 MF=L ORG MacParm MACRO2 MF=L ORG MacParm MACRO3 MF=L ORG , DS 0D . . (other stuff in MyDSECT) . MyPgm RSECT , . MACRO1 MF=(E,MacParm) . MACRO2 MF=(E,MacParm) . MACRO3 MF=(E,MacParm) . . (etc) . -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: IEATDUMP MF=L Can someone explain this?
On 2018-08-27, at 06:20:40, Peter Relson wrote: > >> I've never had the slightest need to use the labels generated in the > MF=L form. Who does? They're not documented. I'll grant that they can > probably be considered self-documenting, but is there a reasonable > guarantee the labels won't be changed in a new release? The MF=E > expansions don't use them (thank goodness), ... >> > The doc (and Peter Relson) seem to say they can and should be used that > way. > > > I'm not positive which "that way" referred to. I don't think I said that > the labels produced by the list form ought to be used. The interface is > the macro. Anything else is not supported (but might well work). > I apologize for any misattribution or misunderstanding. I imagined: ANYMAC MF=(L,AXXX)Defines AXXX ... ANYMAC MF=(E,AXXX)Refers to AXXX defined above If I understand correctly, a similar Example ought to appear in the Users Guide to clarify the use for the OP of this thread. (Everyone is supposed to read the Users Guide.) > > I'd prefer staying with tradition and coding its name in column > one, for legibility. > > > FWIW, I suppose that you could code > LABEL_TRADITIONAL THEMACRO MF=(L,LABEL_NEWFORM),PLISTVER=MAX > and you could use THEMACRO MF=(E,LABEL_TRADITIONAL) > if you must (but the "two labels" would have to be unique) > > For the list form, you would land with > LABEL_TRADITIONAL EQU LABEL_NEWFORM > LABEL_NEWFORM DS0D > ... I'm imagining something like: MACRO WRAPLIST ,,,... MF=(L,),,,... MEND For this sort of thing, I truly miss the POSIX shell constructs: "shift", which discards one or more leading parameters, and "$@", which formats the remaining parameters (think DOUBLE) to be passed to another command. > > I notice that for older macros with "M=L" the parameter > descriptions are in table form; for newer macros with "MF=(L,list addr)" > the descriptions are in outline form. > > I'm not sure what you mean here. Could you provide an example? I think of > the syntax diagram being a table (when it's not RR-track), but the > parameter descriptions being textual. ... > I stand corrected; I didn't read thoroughly. For IEATDUMP, I see: o No RR-track (Blessedly, I suppose.) o "Syntax" Looks like a spreadsheet; I called that "table". o "Parameters" The parameters are explained as follows: ... The parameters and subparameters are variously indented. I called that "outline". So the "spreadsheet" replaces the "RR-track" (which wouldn't fit on the page. Or several pages.) -- gil
Re: IEATDUMP MF=L Can someone explain this?
On Mon, 27 Aug 2018 07:45:08 -0400, Charles Mills wrote: >> making sure that you have allotted the maximum that any of them could need > >How would I make sure of that (other than by "hacking" the macros or by >doing a test assembly)? MF_L_AREA DS 0D MACRO_1_L MACRO1 MF=L ORG MF_L_AREA MACRO_2_L MACRO2 MF=L ORG MF_L_AREA MACRO_3_L MACRO3 MF=L ORG , -- Tom Marchant
Re: IEATDUMP MF=L Can someone explain this?
> I've never had the slightest need to use the labels generated in the MF=L form. Who does? They're not documented. I'll grant that they can probably be considered self-documenting, but is there a reasonable guarantee the labels won't be changed in a new release? The MF=E expansions don't use them (thank goodness), ... > The doc (and Peter Relson) seem to say they can and should be used that way. I'm not positive which "that way" referred to. I don't think I said that the labels produced by the list form ought to be used. The interface is the macro. Anything else is not supported (but might well work). ... so what are they for? Macros that I have had occasion to reference the parmlist for (ATTACH comes to mind), have a perfectly good DSECT macro that I can use when I need it. As long as you don't mind being in unsupported territory. The IEZATTCH and IEZATTCX macros are not programming interfaces. I'd prefer staying with tradition and coding its name in column one, for legibility. FWIW, I suppose that you could code LABEL_TRADITIONAL THEMACRO MF=(L,LABEL_NEWFORM),PLISTVER=MAX and you could use THEMACRO MF=(E,LABEL_TRADITIONAL) if you must (but the "two labels" would have to be unique) For the list form, you would land with LABEL_TRADITIONAL EQU LABEL_NEWFORM LABEL_NEWFORM DS0D ... It's great that the new MF=L macros do not require initialization but is "which ones" documented anywhere? I tend to use a "model" scheme for I cannot imagine anyone trying to make (let alone be willing to keep up to date) a list of "which ones". I could imagine there being a sentence on individual macros saying that the list form need not be used as a "model" (or whatever wording seems suitable). In practice, if the list form supports no keywords other than PLISTVER, it need not be used as a model. In practice, any time that the execute form defaults to "COMPLETE", e.g. MF=(E,mylist,COMPLETE), the list form need not be used as a model -- because "COMPLETE" means that the entire parameter area is to be initialized. I notice that for older macros with "M=L" the parameter descriptions are in table form; for newer macros with "MF=(L,list addr)" the descriptions are in outline form. I'm not sure what you mean here. Could you provide an example? I think of the syntax diagram being a table (when it's not RR-track), but the parameter descriptions being textual. And of course for list form itself, those with MF=(L,list addr) support only PLISTVER or no keywords at all. Peter Relson z/OS Core Technology Design
Re: IEATDUMP MF=L Can someone explain this?
> Consider using the same list area for multiple services Is that documented anywhere? In other words, you are saying -- just to pick three macros that come to mind -- I could issue an ATTACHX, an EXTRACT and a CLOSE and use the same MF=L area for all (assuming the re-sue considerations you list)? > making sure that you have allotted the maximum that any of them could need How would I make sure of that (other than by "hacking" the macros or by doing a test assembly)? So you are saying in essence that there is little or no difference between some MVS MACRO with no keywords except MF=L, and DS nD ? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Peter Relson Sent: Sunday, August 26, 2018 9:23 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEATDUMP MF=L Can someone explain this? Coding a CSECT for the MF=L "model" is, as Gil has pointed out, basically not helpful for those macros that begin by zeroing the entire area, which in turn will be those macros that support no keywords on the list form other than PLISTVER. I'd also suggest that anyone doing a unique getmain for storage for a parameter parameter area ought to re-investigate their approach. If your module already has a getmain for dynamic storage, then include the list form into that area. Consider using the same list area for multiple services (making sure that you have allotted the maximum that any of them could need) if the services cannot be used concurrently (which, for any given reentrant module is "almost always" -- except for something like a case where the service you invoke might branch back to an exit point in your module which might then need to invoke some other service using an execute form). While someone might have gotten burned by the default not being PLISTVER=MAX (specifically on MF=L), a default of PLISTVER=MAX on MF=L would be incompatible and that is why it has not been, and will never be, implemented. A simple problem case is where the list form is part of a DSECT, with other fields after it, when not every user of a DSECT might be recompiled "all the time". We always like to hear your opinions. However, the "label" case is is one where nothing will change. Perhaps if this had been brought up 30 years ago, it might have been different, but I doubt that would have been the case even then. It is unsettling to have two different protocols. I understand that. That's what happens when newer and (we hope) better approaches are developed while still having to maintain the older ones. Peter Relson z/OS Core Technology Design
