Hi Kirk, The existing API header has all the C definitions needed to use the API in C (Metal or not) so no EDCDSECT processing is needed, but the header also includes all the function prototypes, which as we both pointed out are packaged in a DLL and unusable at present from vanilla MetalC programs.
Your option (b) is what I have been experimenting with, using the action IEWBIND macros but using a stripped-down copy of the C API header file without any function prototypes. I originally requested (see the root of this email chain) that someone other than me enter an RFE for the header file to be usable with MetalC for reasons I can't get into here. As I said to Paul, a feature-test in the header for MetalC in the header file to bypass the function prototypes would be a reasonable solution, but I would let IBM choose their own method rather than specify a particular one. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf Sent: Tuesday, August 14, 2018 3:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Using the Binder API and MetalC I believe that the real issue is that the binder api is packaged as a DLL, and AFAIK you need to run under LE and use LE/"C" linkage conventions to call it. Consider writing an RFC for "*z/OS MVS Program Management: Advanced Facilities" *to clarify whether Metal C is supported with the C/C++ DLL Binder APIs. In theory it would be possible to run a Metal C program within an LE environment, you would need assembler stubs for all of the binder apis that could be called from Metal C with MVS linkage and would then call the LE/C binder apis with LE "C" linkage conventions. It seems easier to either: a) write in LE C or C++ b) write in Metal C but call the IEWBIND assembler APIs. Maybe use EDCDSECT to convert mapping DSECTS to C structs. Are they the same mappings as the C/C++ API? I haven't checked. On Tue, Aug 14, 2018 at 1:51 PM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > Indeed. As the XLC/C++ Users Guide states: > > __IBM_METAL__ is predefined to 1 when METAL is in effect. > > But the Binder API header __iew_api.h does not test it. > > Peter > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Paul Gilmartin > Sent: Tuesday, August 14, 2018 1:14 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Using the Binder API and MetalC > > On Mon, 13 Aug 2018 23:07:51 +0000, Farley, Peter x23353 wrote: > > >No feature tests in the header file. As long as the header hasn't > already been used it unconditionally defines the data areas and the > function prototypes. > > > >I'd accept feature test macro(s) as a reasonable alternative as long > >as > MetalC programs can use just the data area definitions and not the > function prototypes. > > > I'd think it most likely that the MetalC compiler defines a feature > macro, but the Binder API header lacks a test for it. > -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
