Thank you all for your prompt replies. Let me see if I can't respond to everyone at once and minimize the listserv noise.
> Charles, you will need two levels to accomplish this from Rexx. First you > need a Rexx function or ADDRESS mode package written in assembler or MetalC > that will load and call your C code the first time, using CEEPIPI to > initialize the C environment, and save the entry point address and the > address of the GETMAIN'ed CEEPIPI area in the user area of one of the Rexx > control blocks or in a saved named whatchamacallit (I forget the macro name – > the z/OS mechanism behind CICS named counters) for subsequent calls. And for > completeness you'll probably need an "exit" call as well to clean up the > loaded code and dynamic storage before Rexx termination. I assume I should take your reply as a Yes to my question. Using CEEPIPI will let the statics and heap persist across Rexx invocations of the C++ code. Yes, I pictured the first of those "levels." I see a sequence in Rexx something like CALL LEENVMGR 'ADD', env-name, 'LE runtime parms', etc. ADDRESS env-name whatever IF RC = 'blah blah blah' THEN ... ADDRESS env-name whatever ADDRESS env-name whatever CALL LEENVMGR 'DELETE', env-name I had not considered the second of those "levels"-- saving the address of the CEEPIPI block and so forth -- but no big deal. I would use the command environment table TOKEN field, or else MVS Name-Token Services, which avoids any conflicts around "user words." > The problem is that z/OS Rexx has no concept of a “load this external > function once and call the same copy the next time”. It sure would be nice > if someone wrote generalized "loaded function" glue code for z/OS Rexx and > contributed it to CBT, but sadly we do not have that yet. This is part of a project destined for the CBT. I would send you the source code for the environment manager once it was working and you could do that, or if you wanted to write up some informal "requirements" for the glue code as you see it I would get it onto the CBT once the main project was done. You're on the CBT Discord, right? You can write me there. I'm assuming that what I have described here is more or less what you are talking about. > Could the C or Assembler refreshable function keep any needed persistent data in Obtained storage and return the address of such a block to REXX? As I said in the OP, "No, an "anchored" GETMAIN is not sufficient. The C++ code makes extensive use of library functions such as map, which is tightly integrated with the language heap." I think that's about it. Writing the environment in HLASM rather than C++ is not on the table. The problem at hand is as stated in the OP. Thanks again, Charles On Sat, 28 Feb 2026 07:55:39 -0600, Charles Mills <[email protected]> wrote: >Here's the problem I am trying to solve. I want to be able to call (from Rexx, >FWIW) one or more entry points in a C++ program multiple times, and have each >call after the first find the heap and statics as the previous call left them. > >In other words, if the Rexx called entry point A and then entry point B, on >entry to B, the statics and heap would be as they were on exit from A. > >Will CEEPIPI let me do this? It looks to me like CEEPIPI(init_sub) will let me >do this. Is that correct? > >CEEPIPI looks IBM-complicated, of course. Is there an easier way to accomplish >what I want? Something with DLL linkage? > >The CEEPIPI doc talks mostly about performance. That's one of the reasons I >wonder if this is the wrong approach. I "get" why pre-initialization would >improve performance, and improved performance is of course a Good Thing, but >that is not my primary goal. The primary goal is being able to put things in >the heap and in statics and use them on subsequent calls. There would >typically be half a dozen or so calls, so improving performance is not a big >consideration. > >No, an "anchored" GETMAIN is not sufficient. The C++ code makes extensive use >of library functions such as map, which is tightly integrated with the >language heap. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
