My reply was indeed a “Yes” answer to your question as to whether what you want
can be done.
Yes, I believe that using CEEPIPI to set up all the entry points you want to
use in the C/C++ code will let the statics and heap persist across Rexx
invocations of the C/C++ code, but the CEEPIPI areas that hold the addresses of
the called routines need to be preserved in obtained storage.
Yes, Name/Token services was the function whose name I could not remember, but
I like your idea of using the host environment command table TOKEN field
better, since that table must have a unique environment name value thus
removing the “user word” conflict issue. Anyone who uses your host environment
name for something other than your environment can’t use your environment, so
no conflict possible.
I did not intend to convey that the actual functionality of the environment
(the C/C++ logic) would need to be coded in assembler or MetalC, only that the
Rexx environment establishment, termination, and CALL interface mechanism would
need to be coded in one of those languages.
Unless I misunderstand Rexx ADDRESS functionality, I think only an initial CALL of the
environment establishment code (to use IRXSUBCM to set up the HOST environment) is
required. Termination can be just one of the "functions" supported by the HOST
environment. Something instead like this:
CALL "HOSTMGR" "ADD", env-name, 'LE runtime parms', etc.
ADDRESS env-name
“function_one params"
IF RC = whatever THEN . . . .
“function_two params"
ADDRESS TSO
"LISTDS" whatever
ADDRESS env-name
“function_three params"
ADDRESS env-name "TERMINATE"
I am on the CBT Discord and will discuss this project further with you there.
Peter
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Charles Mills
Sent: Sunday, March 1, 2026 6:14 AM
To: [email protected]
Subject: Re: Is anyone familiar with CEEPIPI (LE pre-initialization)?
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.
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
