Sounds very good to me, if there is no need in the "REXX calls C" situation
to have some functions which are not available in Metal C.
The different compiles of the same source (one with Standard C, one with
Metal C,
controlled by different #ifdefs) seems to be a good solution - you could
also code
some replacements for functions that are not available in Metal C using
ASSEMBLER
and link them to your Metal C variant, if needed - for example, certain
I/O functions.
Kind regards
Bernd
Am 01.04.2013 13:03, schrieb Lloyd Fuller:
If he is careful, he can even compile C1 for normal C calls and compile it a
second time with Metal C for calling from Rexx. I agree with Charles, calling
from Rexx to Metal C is probably simpler than calling a standard C routine.
We have several routines that we compile both ways: for some things we have a C
or C++ main and use a set of functions compiled with c89. For other uses of
those same functions, we have a little C routine DESIGNED to be called from
assembler that initializes the Metal C library and builds the parameter lists
for the same set of C functions. For a few of the "normal" C functions, we have
some two-way #ifs in the code that says that if this is Metal C you use this set
of #includes and it not Metal C you use a different set.
This all works well.
Lloyd
----- Original Message ----
From: Bernd Oppolzer <[email protected]>
To: [email protected]
Sent: Fri, March 29, 2013 3:27:52 PM
Subject: Re: Linking to MVS standard linkage function from Rexx
I read your post more carefully once again ...
If performance indeed is not critical, why not write two things:
- a C function, let's call it C1, which does the construction of the SMF records
and can be called from the C++ code directly
- and a little C main program C2, which does the conversation with REXX
(gets the needed information from the REXX variables) and builds the
interface to C1, much the same way as the C++ code does it, and then
calls C1.
The C2 main program is called directly from REXX as a command,
and because it is a C main, the LE environment is built on every call.
If this is not executed high frequency, it should work without problems.
Kind regards
Bernd
Am 29.03.2013 20:16, schrieb Bernd Oppolzer:
I don't quite understand why you are restricting yourself by using
Metal C instead of "normal" ANSI C. What is the drawback of using
"normal" C below the REXX application, too? Of course, you may have some
trouble keeping the LE environment alive across different calls, if
performance
is an issue (if not, you may well build the LE environment on every call), but
AFAIK there are ways to do this - isn't it called CEEPIPI? We do it below APL,
for example - well, that's easy, you don't even need CEEPIPI, because APL
supports the construction of persistent environments and a callback to APL,
when the environment has been constructed once - so APL calls an environment
constructing module that you provide on the first call of any application
module
and then never again - this is controlled by APL.
In my opinion it's much easier to get "normal" C running below REXX than
Metal C below C++; maybe it's possible, but IMHO Metal C is meant to be
used in environments like systems programming where you cannot tolerate
the LE overhead, but in your case I believe you can.
Kind regards
Bernd
Am 29.03.2013 19:37, schrieb Charles Mills:
Why?
I have a product coded in Rexx, and a product coded in C++. I want to add
the same function to both of them. FWIW, the function is "writing a user SMF
record." The format of the SMF record is going to be fairly complex, with
four different recurring sections pointed to by triplets.
Rather than write, debug and maintain the "construct the SMF record" logic
twice, once as a method embedded in the C++ code and once in some
combination of Rexx and assembler for the Rexx code, I thought I would write
the logic once in Metal C and call it from the Rexx code and from the C++
code.
I would link it statically with the C++ code. The Rexx code is compiled, and
I would like to link it statically there also. I don't think I can do that
if I want to use LINKMVS/PGM, unless I alias or IDENTIFY it -- that was the
question I was asking -- so I will instead (I think) write a little "Rexx
helper" stub in assembler that is called as a function (part of a function
package) that bridges Rexx linkage to "standard MVS" linkage.
No I/O required. I think what I need to do is a good match for the
capabilities of Metal C. It would not be terribly difficult to do in
assembler but I prefer C. Mostly just pointer logic and memcpy()'s, plus an
invocation of SMFEWTM. Not exactly sure how I will do that, whether with
__asm() or by calling a little assembler routine. I think probably the
latter -- more straightforward, and performance is not critical because it
is a single call.
BTW, you can use malloc() in Metal C, at least according to the
documentation, although I don't think I intend to.
I like static linkage in general. My perception is that it leads to fewer
surprises, although I am also aware of the drawbacks.
Charles
----------------------------------------------------------------------
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
