Thanks much. First, I don't mean to imply that performance does not matter at all. I was speaking specifically of the invocation of SMFEWTM, which is only done once. In the design I have, yes, the function being discussed gets called multiple times: basically add this piece to the record, add another piece to the record, ..., write the record, and I would like the whole thing to be reasonably economical in terms of CPU and wall clock time.
I am failing to grasp -- I believe you, I am just failing to grasp -- why you can't call Metal C from C++. If I can call assembler, why can't I call Metal C. I thought the idea of Metal C was that it could be used "anywhere" -- places that formerly required assembler. Why wouldn't anywhere include from C++? These are serious questions -- I hope someone enlightens me. Yes, I understand that I could not pass C++ callbacks or depend on overloading or polymorphism or anything. I am expecting nothing from Metal C that could not be done, with somewhat more work, in assembler. Perhaps I will experiment a bit and post the results back here. Yeah, I get your architecture. Most of the logic in a function that would be called either from the C++ code or from a little main() front-end from Rexx, and use CEEPIPI to keep the environment around from Rexx call to call. I will think about that. I think the basic question I was asking -- as I look at Rexx linkage now I guess I can start from __R1 and pick up all of the Rexx parameters by chaining from there. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer Sent: Friday, March 29, 2013 12:28 PM To: IBM-MAIN@LISTSERV.UA.EDU 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
