Thank you David. If I understand correctly then, the returned "token" is unique to each call of __cinit, and as long as __cinit / __cterm are properly nested they should not interfere with each other, right?
I very much like your idea of using nested __cinit / __cterm to create unique heaps and then "clean up" in one call after heavy use of (m/c/re)alloc. Makes a lot of sense as long as nothing allocated in that scope needs to be passed back up out of scope. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of David Crayford Sent: Friday, September 21, 2012 12:38 AM To: [email protected] Subject: Re: Metal C runtime safe for dynamic LINKing? On 21/09/2012 12:09 AM, Farley, Peter x23353 wrote: > *** Comments and questions marked below. > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of David Crayford > Sent: Thursday, September 20, 2012 11:40 AM > To: [email protected] > Subject: Re: Metal C runtime safe for dynamic LINKing? > > __cinit returns an environment token which is stored in R12. > > *** I am aware of that, since there is source coding required to support the > use and reservation of R12 for the token. AFAIK, all __cinit() does is create a storage heap, and __cterm() destroys it. I'm not sure if any of the runtime actually uses the heap, the manual eludes to this by documenting the required stack sizes of the runtime functions. I've nested several __cinit/__cterm calls in the same program because I wanted to create a new heap that I could tear down in one call and thus reduce the overhead of tens of thousands of free() calls. This technique is similar to memory pools or user heaps. Metal/C is pretty low-level, no anchored control blocks or anything sophisticated to worry about. > It's not unusual to have environment pools in both metal/c and LE using PIPI. > > *** I do not understand this part of your reply. I am well aware of the use > of PIPI for LE programs to prevent repeated startup and teardown of the LE > environment. But what do you mean by "environment pools"? And how do they > relate to my question, please? It doesn't really relate to your question, sorry about that! I was talking about the technique of reusing PIPI environments from a free pool. Only really interesting to PIPI heavy users who probably already know about it. > Peter > > On 20/09/2012, at 11:00 PM, "Farley, Peter x23353" > <[email protected]> wrote: > >> In thinking about a possible Metal C project, I realized I might have to >> LINK to other Metal C main programs as part of the project. My concern in >> this OCO environment is whether this scenario is safe to plan: >> >> EXEC PGM=A >> __cinit >> (Program A logic) >> LINK to program B >> __cinit >> (Program B logic) >> __cterm >> RETURN to program A >> (Program A more logic) >> __cterm >> RETURN to z/OS >> >> My first question is whether the Program B invocation of __cinit will >> succeed since __cinit was already called by Program A. >> >> If the answer to the first question is Yes, then my second question is >> whether the (Program A more logic) section would succeed or fail using the >> Metal C runtime routines after the LINKed-to program B calls __cterm. >> >> TIA for any practical experience or advice you can provide. >> >> Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
