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 <bernd.oppol...@t-online.de> To: IBM-MAIN@LISTSERV.UA.EDU 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 >> > -- 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
