Other than the C++ runtime it's a piece of cake. You need glue code callable from REXX to initialize and terminate the C++ code. The glue code can read and write REXX variables. The CALL interface supports multiple string parameters and returning a string value. Any address you need to pass would be stored in a 4 (31 bit) or 8 (64 bit) character string. I see no need to convert it to hexadecimal, but there's a BIF if you want to display debugging information.
Note: I'm not saying that the C++ side is harder, just that I don't know. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Paul Gilmartin <[email protected]> Sent: Saturday, February 28, 2026 8:42 PM To: [email protected] <[email protected]> Subject: Re: Is anyone familiar with CEEPIPI (LE pre-initialization)? External Message: Use Caution On Sun, 1 Mar 2026 00:32:45 +0000, Farley, Peter wrote: >Sure, as long as the called program Is prepared to access the Rexx variable >argument in which to read or return the address value. Alternatively, I >suppose you could try to set the return code to the address of the obtained >storage, but I am not sure the whole value would survive unless Rexx NUMERIC >DIGITS was high enough. Might be worth a try though. > Pass it as hex using REXX conventions and return it as a function result. But better, since neither REXX nor HLASM uses null-terminated strings and all EBCCDIC characters are valid, imply pass the binary values. C2X(), C2D(), STORAGE(), etc. may be your friends here. There are ICSF examples in SAMPLIB interesting because they rely on the called program modifying the passed arguments. The CALL macro has no rule against this. Alas, BPXWDYN <https://www.ibm.com/docs/en/zos/3.2.0?topic=conventions-conventional-mvs-parameter-list> reserves NUL. I believe this is not generally true of REXX. I would *never* rely on the persistent address of a REXX string because the undocumented behavior of REXX storage management night move it during garbage collection. >Using ADDRESS MVS or ADDRESS LINKMVS doesn’t keep the executed program loaded. > Ideally you would like to have something like ADDRESS KEEPMVS in place of >LINKMVS or MVSKEEP in place of MVS (or any better naming convention you >prefer, I just made those names up in the moment). > I've also wished for a truly concurrent ATTACH, but never coded it. It would need to copy the parameters before return, again because ofREXX storage management. -- gil ---------------------------------------------------------------------- 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
