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
Re: IEATDUMP MF=L Can someone explain this?
On 2018-08-26, at 19:22:54, Peter Relson wrote: > 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 > I don't recall saying that. Perhaps credit Ed Jaffe? > 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) > Aha! A tour de force in ORG! > if the services cannot be used concurrently ... > 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, ... > Bummer. Making the List and Execute forms homologous is similar to the design motive of declarators in C. And that comparison alone may be enough to alienate staunch assembler partisans. -- gil
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
Re: IEATDUMP MF=L Can someone explain this?
My guess is that DFSMS is SOOO LARGE it is Godzilla size Lizette > -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of David Stokes > Sent: Sunday, August 26, 2018 12:09 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: AW: IEATDUMP MF=L Can someone explain this? > > Who thought up the name IGDZILLA? > > Maybe the same people who thought up $DILBERT and $DOGBERT? > > Although I doubt JES2 talks to SMS very often. > > -Ursprüngliche Nachricht- > Von: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] Im > Auftrag von Seymour J Metz > Gesendet: Sonntag, 26. August 2018 20:53 > An: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Betreff: Re: IEATDUMP MF=L Can someone explain this? > > I hate censorware. Scunthorpe would pass muster in California either. > > The prefix IEA goes all the way back to OS/360; it's Supervisor. The T, of > course, is Transaction. > > Who thought up the name IGDZILLA? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List on > behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> > Sent: Saturday, August 25, 2018 5:26 PM > To: ASSEMBLER-LIST@listserv.uga.edu > Subject: Re: IEATDUMP MF=L Can someone explain this? > > On 2018-08-25, at 14:27:44, Charles Mills wrote: > > > +2 > > > > Labels belong in column 1 where your eye can scan for them. > > > Who thinks up these macro names, anyway? That one wouldn't pass muster as a > California vanity license plate. > > > 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 initializing the DSECT with the MF=L's that works well for me, so > > I always use it. > > > I once tried to define a prototype with DCs; move it into obtained storage > for reentrancy, then map it with dependent USINGs. No luck; got ambiguous > resolution. Would have worked if dependent USING allowed for a lower bound > as well as an upper bound. (64-bit is a greater challenge.) > > -- gil
Re: IEATDUMP MF=L Can someone explain this?
I hate censorware. Scunthorpe would pass muster in California either. The prefix IEA goes all the way back to OS/360; it's Supervisor. The T, of course, is Transaction. Who thought up the name IGDZILLA? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Saturday, August 25, 2018 5:26 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: IEATDUMP MF=L Can someone explain this? On 2018-08-25, at 14:27:44, Charles Mills wrote: > +2 > > Labels belong in column 1 where your eye can scan for them. > Who thinks up these macro names, anyway? That one wouldn't pass muster as a California vanity license plate. > 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 > initializing the DSECT with the MF=L's that works well for me, so I always > use it. > I once tried to define a prototype with DCs; move it into obtained storage for reentrancy, then map it with dependent USINGs. No luck; got ambiguous resolution. Would have worked if dependent USING allowed for a lower bound as well as an upper bound. (64-bit is a greater challenge.) -- gil
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.
Re: IEATDUMP MF=L Can someone explain this?
On 2018-08-25, at 17:22:52, Charles Mills wrote: > >> I once tried to define a prototype with DCs; > > Briefly, here is what I do: > > - Code a separate CSECT for my "model" (as I call it) > ... Costs a base register, but only very briefly. Or is there now a SS instruction where the source is relative but the destination is based? A colleague shuns multi-CSECT assemblies because in prehistoric times the assembler erroneously persumed addressability across CSECT boundaries. I was never able to reproduce the problem, but once burned forever shy. And another resorted to multiple CSECTs only to suppress USING warnings. I showed her how the upper bound on USING could avoid the problem. She shunned that: too avant garde for her, or she feared our other colleagues would be baffled by the construct. But at least she named the CSECT after I warned her that unnamed CSECTs accumulate endlessly with SMP/E maintenance. -- gil
Re: IEATDUMP MF=L Can someone explain this?
> That one wouldn't pass muster as a California vanity license plate Geez. Had not noticed that. Sheesh! > I once tried to define a prototype with DCs; Briefly, here is what I do: - Code a separate CSECT for my "model" (as I call it) - Code all of the MF=L and constants and so forth there - Define a symbol for the length of all of it - GETMAIN or otherwise allocate reentrant storage of that length - MVC or MVCL the CSECT storage to the reentrant storage for the defined length - Address the reentrant storage with USING model_CSECT,rent_storage Because it is a separate CSECT there is no addressing ambiguity. I could try to post a more complete version if anyone is interested. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, August 25, 2018 5:26 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEATDUMP MF=L Can someone explain this? On 2018-08-25, at 14:27:44, Charles Mills wrote: > +2 > > Labels belong in column 1 where your eye can scan for them. > Who thinks up these macro names, anyway? That one wouldn't pass muster as a California vanity license plate. > 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 > initializing the DSECT with the MF=L's that works well for me, so I always > use it. > I once tried to define a prototype with DCs; move it into obtained storage for reentrancy, then map it with dependent USINGs. No luck; got ambiguous resolution. Would have worked if dependent USING allowed for a lower bound as well as an upper bound. (64-bit is a greater challenge.)
Re: IEATDUMP MF=L Can someone explain this?
On 2018-08-25, at 14:27:44, Charles Mills wrote: > +2 > > Labels belong in column 1 where your eye can scan for them. > Who thinks up these macro names, anyway? That one wouldn't pass muster as a California vanity license plate. > 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 > initializing the DSECT with the MF=L's that works well for me, so I always > use it. > I once tried to define a prototype with DCs; move it into obtained storage for reentrancy, then map it with dependent USINGs. No luck; got ambiguous resolution. Would have worked if dependent USING allowed for a lower bound as well as an upper bound. (64-bit is a greater challenge.) -- gil
Re: IEATDUMP MF=L Can someone explain this?
+2 Labels belong in column 1 where your eye can scan for them. 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 initializing the DSECT with the MF=L's that works well for me, so I always use it. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, August 25, 2018 1:39 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEATDUMP MF=L Can someone explain this? On 2018-08-25, at 11:20:42, Steve Smith wrote: > Just in case anyone cares about my HO, I hate the "new" syntax, and think the list forms are hideous. While I agree they are documented adequately, putting the label as a required 2nd sub-operand of MF=L is terrible. Labels belong in column one (I am aware of the option to put an alias there). > +1
Re: IEATDUMP MF=L Can someone explain this?
On 2018-08-25, at 11:20:42, Steve Smith wrote: > Just in case anyone cares about my HO, I hate the "new" syntax, and think the > list forms are hideous. While I agree they are documented adequately, putting > the label as a required 2nd sub-operand of MF=L is terrible. Labels belong > in column one (I am aware of the option to put an alias there). > +1 > 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. > ... 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. > Beware: LABELEQU * WOMBAT MF=L can run afoul of alignment needs. But the macro can satisfy alignment with: LABELWOMBAT MF=L by putting that label on the first generated instruction. It's better to have the macro define the symbol for you, but I'd prefer staying with tradition and coding its name in column one, for legibility. -- gil
Re: IEATDUMP MF=L Can someone explain this?
Just in case anyone cares about my HO, I hate the "new" syntax, and think the list forms are hideous. While I agree they are documented adequately, putting the label as a required 2nd sub-operand of MF=L is terrible. Labels belong in column one (I am aware of the option to put an alias there). 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), 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. Most of the newer macros don't allow you to specify anything else on the MF=L form, so the only use I have for them is to get the length of storage required*. That's how I use them, all hidden in a NOGEN pile somewhere I don't have to look at them. *I don't even trust this anymore, as I've been burned by PLISTVER not defaulting to MAX. To be clear, this is just my opinion, not a complaint. These macros work well enough, and don't interfere with me getting work done. I just think the old conventions were better. Tastes differ, and if some people find this style useful, that's great. sas On 8/25/2018 9:06, Peter Relson wrote: The documentation seems quite clear to me. Almost every macro written in the last 20+ years has used this same syntax for the list form. We felt it best to have the syntax for list form be analogous to that for execute and modify forms. The syntax diagram shows the valid format. As does the parameter description. For example, ,MF=(L,list addr) ,MF=(L,list addr,attr) ,MF=(L,list addr,0D) You mention a "DSECT". I cannot think of any case where a list form builds a DSECT. You might put a list form within a DSECT. But that is your DSECT. Peter Relson z/OS Core Technology Design
Re: IEATDUMP MF=L Can someone explain this?
On 2018-08-25, at 07:06:30, Peter Relson wrote: > The documentation seems quite clear to me. Almost every macro written in > the last 20+ years has used this same syntax for the list form. We felt it > best to have the syntax for list form be analogous to that for execute and > modify forms. > Most of my assembler use antedates 20+ years ago (FSVO "+"). I was familiar with only the "MF=L" form, not "MF=(L,list addr)". I believe that what the OP stumbled on is that the List form *defines* the symbol "list addr"; the Execute form *refers* to a symbol defined by that List form. Yes, the documentation says, "The list form defines an area of storage". It's reasonable to assume, as the OP apparently did, that "list addr" refers to a storage area provided by the user, and that the list form defines its content. Better would be, '"The list form defines an area of storage and defines the symbol 'list addr' to the beginning of that area". Repeating that description for every macro would be tedious. Better would be a section in the Users Guide describing techniques for using List and Execute forms. (Interesting: 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. A distressing inconsistency, but I suspect the resource to make it consistent (without introducing errors) is unavailable.) > The syntax diagram shows the valid format. As does the parameter > description. > > For example, > > ,MF=(L,list addr) > ,MF=(L,list addr,attr) > ,MF=(L,list addr,0D) > > You mention a "DSECT". I cannot think of any case where a list form > builds a DSECT. You might put a list form within a DSECT. But that is your > DSECT. -- gil
Re: IEATDUMP MF=L Can someone explain this?
On 8/25/2018 6:06 AM, Peter Relson wrote: You mention a "DSECT". I cannot think of any case where a list form builds a DSECT. You might put a list form within a DSECT. But that is your DSECT. Indeed. Putting the list form in a DSECT is the preferred approach these days since (almost?) every macro written in the last 20 years has no requirement to copy a model parameter list from the static area before using the execute form. -- 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?
The documentation seems quite clear to me. Almost every macro written in the last 20+ years has used this same syntax for the list form. We felt it best to have the syntax for list form be analogous to that for execute and modify forms. The syntax diagram shows the valid format. As does the parameter description. For example, ,MF=(L,list addr) ,MF=(L,list addr,attr) ,MF=(L,list addr,0D) You mention a "DSECT". I cannot think of any case where a list form builds a DSECT. You might put a list form within a DSECT. But that is your DSECT. Peter Relson z/OS Core Technology Design
Re: IEATDUMP MF=L Can someone explain this?
On 2018-08-24, at 12:50:35, Steve Thompson wrote: > Well, after looking at the code that is generated, I really do think that > this was done this way for PLAX (or whatever it is today) users and NOT HLASM > programmers. > > And the manual needs to explain this better. This is the label prefix for all > the labels that will be generated by this expansion. > An example demonstrating the List and Execute forms would be valuable. RCF? > I say this because Whatever it is you put in the second parm, becomes the > label prefix. And then each field has its own label with that prefix. > A clever idea. More macros should have this facility. But it's 'way late to change horses. -- gil
Re: IEATDUMP MF=L Can someone explain this?
Well, after looking at the code that is generated, I really do think that this was done this way for PLAX (or whatever it is today) users and NOT HLASM programmers. And the manual needs to explain this better. This is the label prefix for all the labels that will be generated by this expansion. I say this because Whatever it is you put in the second parm, becomes the label prefix. And then each field has its own label with that prefix. And the label on the MACRO call is put into the source like this: IEATDUMP_L IEATDUMP PLISTVER=MAX,MF=(L,IEATDUMP_S) +IEATDUMP_L EQU IEATDUMP_S +IEATDUMP_S DS OD +IEATDUMP_S_... One would have expected that a DSECT macro would be be required to be generated... You know, like IHAPSA, or IKJTCB, or IEFZB4d0, or ... Regards, Steve Thompson On 08/24/2018 02:23 PM, Mike Shaw wrote: We have the list form coded like this: IEATDUMP PLISTVER=MAX,MF=(L,IEATDUMPL) and the execute form coded like this: IEATDUMP DSN=DUMPDSNL,HDR=DUMPTITL, PLISTVER=MAX, MF=(E,IEATDUMPL) Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: IEATDUMP MF=L Can someone explain this?
We have the list form coded like this: IEATDUMP PLISTVER=MAX,MF=(L,IEATDUMPL) and the execute form coded like this: IEATDUMP DSN=DUMPDSNL,HDR=DUMPTITL, PLISTVER=MAX, MF=(E,IEATDUMPL) Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. >
