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 -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lloyd Fuller Sent: Friday, March 29, 2013 11:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linking to MVS standard linkage function from Rexx I am not sure WHY you would want to do this: imbed assembler maybe? You would not be able to use malloc or most of the C functions. The Metal C functions resolve into different functions than normal C compiles. Also, unless you play games you cannot do I/O in Metal C (i.e. sprintf() works, but printf() does not). Many of the C functions have no Metal C equivalent, for example, the time and date ones, ICONV, etc. It may be doable, but I would be very careful. Also, if you are going to ship this as part of the product, you need to use static linkage for the Metal C part particularly if you need to do __cinit. The underlying function changed between z/OS 1.11 and 1.12 and they are not necessarily compatible in execution. Been bitten there. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
