On Fri, 28 Mar 2025 at 13:18, Schmitt, Michael <[email protected]> wrote:
> It is a valid technique but the disadvantage is now the caller is > determining the size of the area. If you're not in control of both the > calling program and the subprogram, you have problems when the subprogram > has changes that need more memory. > This is what CXD, DXD and so on are for. At linkedit/binder time the total size of all the work areas is put into a single place, and the startup/calling program gets that much storage at runtime. If you change a subprogram you just rebind and everything looks after itself. I'm not sure why this style of program management went out of style, but it certainly still works. I guess if you have a lot of recursive calls you need to do something else, but how common is that in the real world? Tony H. -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Richard Zierdt > Sent: Friday, March 28, 2025 10:49 AM > To: [email protected] > Subject: Reentrant Lite ? > > When coding reentrant modules, one practice is to Obtain Storage (Getmain, > etc) and setup shop. This is well and good. > > But another technique would have the *caller*, who may be reentrant or > not, *provide* the savearea / workarea and pass the address of that area > through typical R1 / address list linkage stuff. > > This would save Obtain / Getmain / Freemain calls. For a program that > gets called thousands of times, the overhead would add up. Yes, the > caller has to provide a workarea, and that may cost one Getmain, but it's > only once. > > Say Program A calls reentrant Program B 10,000 times. If A provides the > workarea, that saves 10,000 Getmain/Freemains in B. > > The concept seems to be used by the IEAMSXMP "POST" macro, which wants a > 512-byte WORKAREA=. Well, why not get it yourself, IBM? Answer might be > to save overhead. (Yes, there may be other reasons). > > Any program could be reentrant without Getmains if callers provided > save/work areas (and the programs were written accordingly). > > Just a thought > > Richard Zierdt > > Confidentiality Warning/Avertissement de confidentialité: > > This message is intended only for the named recipients. This message may > contain information that is privileged or confidential. If you are not the > named recipient, its employee or its agent, please notify us immediately > and permanently destroy this message and any copies you may have. Ce > message est destiné uniquement aux destinataires dûment nommés. Il peut > contenir de l'information privilégiée ou confidentielle. Si vous n'êtes pas > le destinataire dûment nommé, son employé ou son mandataire, veuillez nous > aviser sans tarder et supprimer ce message ainsi que toute copie qui peut > en avoir été faite. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
