Agreed!
The set-up/tear-down of LE is a pain.
In a previous life, I brought up LE to have it available for C (or any
other LE languages) sort of on demand. Calling linkage to/from the other
languages worked fine. It was that LE establishment that would lead to
ABENDs if not done (or if not done right).
And yeah ... C structs. No biggie.
-- R; <><
On 11/15/23 20:12, David Crayford wrote:
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
