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
--
Bernd Oppolzer
---------------------------------------------------------------
*Oppolzer-Informatik
* Dipl. Inf. Bernd Oppolzer
Bärenhofstraße 23
70771 Leinfelden-Echterdingen
---------------------------------------------------------------
Tel.: +49 711 2272522
priv.: +49 711 7949590
eMail: bernd.oppol...@t-online.de <mailto:bernd.oppol...@t-online.de>
---------------------------------------------------------------
Für Umsatzsteuerzwecke:
SteuerNr.: 97 076 / 29921
USt-ID-Nr.: DE 147 700 393
---------------------------------------------------------------
Jubiläumsjahr 2013:
30 Jahre Oppolzer-Informatik
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
