There isn’t an R0 issue. IRXINIT(‘FINDENVB’) will fetch the environment block. All of the REXX mapping macros have been converted to C structures and can be found in /usr/include/zos (there is a PDS/E but I can’t remember what it's called). FWIW, writing external functions in C/C++ is a bad idea unless it’s main routine. The overhead of standing up and ripping down an LE environment is huge. Metal/C is an option. It’s one of the reasons why I don’t like REXX, it’s difficult to extend with languages other than assembler which makes it useless for what I want for a glue language.
> On 16 Nov 2023, at 2:06 am, Charles Mills <charl...@mcn.org> wrote: > > @Peter, I went around on the R0 question here a couple of years ago. > > - No, I don't think there is a reliable way to get the entry R13 from within > the C/C++ code. Obviously, if you could, then any other register is trivial. > > - Yes, people suggested inline assembler. I rejected that approach -- it may > be completely viable but I rejected it -- because > > a. I am just not a fan of inline assembler. Call it personal preference. I > think the syntax seems kludgey. I prefer an external module written in "real" > assembler. I fully accept that this is just my personal opinion and others > who think otherwise are just as valid. > b. IIRC the logic was a little bit unsupported. XLC is stable now, so it > would probably be safe, but for me that was another nail in the coffin of the > in-line assembler approach. > > The code is exactly 11 executable instructions, four of them because I set up > an eyecatcher that is not really necessary. > > I do it without a save area. I branch to the C code with the assumption that > the C code will ultimately return to *my caller* and not to me. > > FWIW, I pass R0 in the EVALBLOCK data area, a totally "safe" spot that does > not require a GETMAIN. > > Charles > > On Wed, 15 Nov 2023 17:54:44 +0000, Farley, Peter > <peter.far...@broadridge.com> wrote: > >> Isn’t there is some C library function (maybe unique to XLC/C++) that lets >> you get the value of R13 (current DSA pointer)? With that pointer value in >> hand, couldn’t one chain up the DSA stack to get to the saved registers at >> entry, or is that not possible? >> >> At worst, an inline ASM routine to copy the value of the current R13 to a C >> pointer variable, then chain up the DSA stack? >> >> Peter >> >> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of >> Charles Mills >> Sent: Wednesday, November 15, 2023 12:39 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: External Functions in C on z/OS >> >> >> I see, in my C++ projects, EFPL, ENVB, EVALB and SHVB structs that appear to >> me to have been produced from IBM macros by the EDCDSECT tool. >> >> >> >> Have you looked for the IRX macros in SYS1.MACLIB? >> >> >> >> Are you familiar with EDCDSECT? >> >> >> >> Slightly changing the subject, to interface with ehe Rexx environment from a >> called function you will need the entry R0, I found no great way to get >> that. I had to write a tiny front end in assembler that passes R0 to a C/C++ >> main(). >> >> >> >> Charles >> >> >> >> On Wed, 15 Nov 20 3 10:57:14 -0600, Eric Erickson <esf...@windstream.net> >> wrote: >> >> >> >>> I've written quite a few callable external funitions for Rexx over the >>> years. On z/OS I've always used assembler as we needed to access system >>> services for a variety of tasks. I've written them in C for other platforms >>> (OS/2 & Windows) over the years. I need to write some on z/OS, but I want >>> to use C, but can not seem to find any examples or header files for the >>> Rexx Control Blocks. I can't believe nobody has done this over the years? >>> Is it even supported? >> >> >> >> -- >> >> 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
