Re: Linking to MVS standard linkage function from Rexx
You can use malloc() in Metal C. We do. My point was that the malloc() in Metal C is a different routine than the malloc() in the LE library. Also, to use malloc() and some of the other Metal C functions, you need to call __cinit. I am not sure how you do that when you are also linking with the LE library. Can you do an external load with C++ like you can with COBOL: i.e., CALL 'name' or CALL variable_name? If you can do that, I think that you might be safe. I just suspect that you are going to have some problems linking Metal C and a standard C/C++ routine. Lloyd - Original Message From: Charles Mills charl...@mcn.org To: IBM-MAIN@LISTSERV.UA.EDU Sent: Fri, March 29, 2013 2:37:46 PM Subject: Re: Linking to MVS standard linkage function from Rexx 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linking to MVS standard linkage function from Rexx
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
Re: Linking to MVS standard linkage function from Rexx
Great minds think alike! I am now thinking that perhaps I write the SMF build logic in the Metal C subset dialect, but then compile it two ways: 1. With Metal C for linking with Rexx. 2. With standard C (is there a name for non-metallic C? Plastic C?) for linking with the C++ code. Along with the advantage of avoiding the sorts of problems you allude to, another advantage would be that I could sneak some printf's for debugging purposes into the standard C compile, and then after debugging comment them back out of the source before doing the Metal C compile. (Or use #ifdefs.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lloyd Fuller Sent: Monday, April 01, 2013 4:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linking to MVS standard linkage function from Rexx 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linking to MVS standard linkage function from Rexx
I think you are safer that way. We have code that does the __cinit() call for our Metal C routines that is in a separate routine that never gets compiled with normal C. I see no reason why you could not put it into your function and use #ifdefs to not compile it when you are using standard C. And our define for the Metal C compiles and #ifdefs is METAL_C so it is obvious which code is specific to that compile. Two warnings: since you are going to different platforms with your product, make sure you do a static compile and bind with the Metal C. We ran into issues compiling on z/OS 1.12 and trying to run on 1.11. Once we did things static we were fine on both platforms. Also, if you are going to use 64-bit, there is a documentation issue in the __cinit() sample code. You do NOT need to cast the return from the __cinit() call for 64-bit or 32-bit. You will get compile errors if you try it use the sample code as it. Lloyd - Original Message From: Charles Mills charl...@mcn.org To: IBM-MAIN@LISTSERV.UA.EDU Sent: Mon, April 1, 2013 10:03:56 AM Subject: Re: Linking to MVS standard linkage function from Rexx Great minds think alike! I am now thinking that perhaps I write the SMF build logic in the Metal C subset dialect, but then compile it two ways: 1. With Metal C for linking with Rexx. 2. With standard C (is there a name for non-metallic C? Plastic C?) for linking with the C++ code. Along with the advantage of avoiding the sorts of problems you allude to, another advantage would be that I could sneak some printf's for debugging purposes into the standard C compile, and then after debugging comment them back out of the source before doing the Metal C compile. (Or use #ifdefs.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lloyd Fuller Sent: Monday, April 01, 2013 4:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linking to MVS standard linkage function from Rexx 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. -- 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
Re: Linking to MVS standard linkage function from Rexx
Thanks! Will keep this forum informed. - Intention is static -- I like the certainty. - No 64-bit. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lloyd Fuller Sent: Monday, April 01, 2013 8:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linking to MVS standard linkage function from Rexx I think you are safer that way. We have code that does the __cinit() call for our Metal C routines that is in a separate routine that never gets compiled with normal C. I see no reason why you could not put it into your function and use #ifdefs to not compile it when you are using standard C. And our define for the Metal C compiles and #ifdefs is METAL_C so it is obvious which code is specific to that compile. Two warnings: since you are going to different platforms with your product, make sure you do a static compile and bind with the Metal C. We ran into issues compiling on z/OS 1.12 and trying to run on 1.11. Once we did things static we were fine on both platforms. Also, if you are going to use 64-bit, there is a documentation issue in the __cinit() sample code. You do NOT need to cast the return from the __cinit() call for 64-bit or 32-bit. You will get compile errors if you try it use the sample code as it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linking to MVS standard linkage function from Rexx
Thanks, Tony, SPC had in fact escaped my attention. I either never saw it, or ran it together with Metal C in my mind. (Yes, I am now clear on the difference.) I think the Metal C looks like a better fit for what I am trying to do. No progress on this project today. Other fish jumping into the frying pan on April Fools' Day. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Monday, April 01, 2013 11:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Linking to MVS standard linkage function from Rexx On 1 April 2013 10:03, Charles Mills charl...@mcn.org wrote: I am now thinking that perhaps I write the SMF build logic in the Metal C subset dialect, but then compile it two ways: 1. With Metal C for linking with Rexx. 2. With standard C (is there a name for non-metallic C? Plastic C?) for linking with the C++ code. Probably LE C describes it best. But keep in mind that there's effectively a third kind of C: System Programming C. This is the same compiler (and same object output) as LE C, but with a different run-time environment that replaces (some of) LE with minimalist routines that provide basic services. And as with Metal C, there is no SPC++... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linking to MVS standard linkage function from Rexx
Charles, Before you get to far, unless things have changed, Metal C does not handle C++. C only. I have not looked specifically at z/OS 1.13, but I do know that in 1.12 and earlier, C only. Lloyd - Original Message From: Charles Mills charl...@mcn.org To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thu, March 28, 2013 8:59:05 PM Subject: Linking to MVS standard linkage function from Rexx Level set: I know what I am doing in Rexx. I am real familiar with and have written function packages already. I want to write a function that will be callable both from Rexx and from C++. (This may be my first adventure with Metal C, but that's a different topic.) The C++ part is easy; let's talk about the linkage from Rexx. I know I can call from Rexx using standard MVS linkage using ADDRESS LINKMVS or LINKPGM. (We just went over the differences here; let's not digress into that!) But if I am RTFM correctly, LINKMVS/PGM requires a separate load module or alias (or IDENTIFY and I don't think I want to go there for this). For the sake of neater packaging I would like to linkedit the callable function into an existing function package. Relying on separate load modules or PDS aliases complicates life in other ways. I don't *think* I can make a standard MVS linkage function part of a Rexx function package, is that right? LINKMVS/PGM and Rexx functions live in different worlds, right? LINKMVS/PGM always searches for MVS entry points, and only Rexx functions use function packages, is that right? If I want to do this then instead of using LINKMVS/PGM I will have to write a Rexx linkage Rexx function that provides a glue layer between Rexx and the standard MVS linkage function? Or does anyone know something I am missing? Thanks! Charles -- 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
Re: Linking to MVS standard linkage function from Rexx
On 3/29/2013 5:19 AM, Lloyd Fuller wrote: ... unless things have changed, Metal C does not handle C++. C only. I have not looked specifically at z/OS 1.13, but I do know that in 1.12 and earlier, C only. True in z/OS 1.13 as well. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
