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
