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
