> 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
