OK, I sort of understand the “personal preference” about not using inline assembler (it is kludgey, I agree) and somewhat understand the concern about the “unsupported” aspect of retrieving register contents at entry, but if that is the case why not use MetalC where you have much more control of the entry and exit logic, and could easily provide your own version of the prolog that guaranteed access to the contents of R0? Is there some C library routine that is not provided by MetalC that you would need in your Rexx external function?
Also you are correct that IBM does not supply C versions of the Rexx or TSO control blocks. Like Colin, I cobbled together my own collection of them from the assembler macro library source using the EDCDSECT utility and some semi-automated post-processing. Peter From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Charles Mills Sent: Wednesday, November 15, 2023 1:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: External Functions in C on z/OS @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
