Peter, I just ran into a customer issue using LE Cobol and I *think* it applies to C. We run amode(31) rmode(any) ..customers run options were all31(off) and stack( ,,,below,,) . We were getting S0c4-11, we couldn't reproduce it until we examined their ripen options against ours line by line and found it. So you have to be careful in the design of LE code for sure.
Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Sep 21, 2012, at 12:43 PM, Kirk Wolf <k...@dovetail.com> wrote: > As I understand it, you only need to make sure that your code uses the > right environment token (returned as R12). > So, you could switch between environments if careful. > > Kirk Wolf > Dovetailed Technologies > http://dovetail.com > > On Fri, Sep 21, 2012 at 10:48 AM, Farley, Peter x23353 < > peter.far...@broadridge.com> wrote: > >> 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:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of David Crayford >> Sent: Friday, September 21, 2012 12:38 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> 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:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of David Crayford >>> Sent: Thursday, September 20, 2012 11:40 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> 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" < >> peter.far...@broadridge.com> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
