Discussion:
Using the Binder API and MetalC
(too old to reply)
Farley, Peter x23353
2018-08-13 18:29:41 UTC
Permalink
I have been experimenting with MetalC code to invoke the Binder API macros (IEWBIND) and access the returned data using the C language definitions in /usr/include/__iew_api.h.

The issue is that /usr/include/__iew_api.h also contains all of the actual Binder API function prototypes and these cannot (easily) be used from MetalC because they reside in a DLL, plus it appears to me that they are only useable in an LE enclave, also not easily done from MetalC.

OTOH, the C language buffer and data area definitions are perfectly usable in MetalC as they are.

I was thus forced to make a copy of the /usr/include/__iew_api.h structure and data area definitions without the function prototypes. This works well for my immediate need, but for future maintainability it sure would be nice if IBM split the /usr/include/__iew_api.h into two parts - Data definitions and function prototypes.

Or create two new header files for each and make /usr/include/__iew_api.h just #include the two new headers to preserve the current functionality.

Would some kind soul volunteer to set up an RFE for that? I would do so myself but for various reasons I cannot do it at this time.

Peter


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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-08-13 22:09:45 UTC
Permalink
... for future maintainability it sure would be nice if IBM split the /usr/include/__iew_api.h into two parts - Data definitions and function prototypes.
Or create two new header files for each and make /usr/include/__iew_api.h just #include the two new headers to preserve the current functionality.
Or. conditional compilation. Might there already be a feature test macro for MetalC?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2018-08-13 23:08:02 UTC
Permalink
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.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Monday, August 13, 2018 6:10 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Using the Binder API and MetalC
... for future maintainability it sure would be nice if IBM split the /usr/include/__iew_api.h into two parts - Data definitions and function prototypes.
Or create two new header files for each and make /usr/include/__iew_api.h just #include the two new headers to preserve the current functionality.
Or. conditional compilation. Might there already be a feature test macro for MetalC?

--


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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
David Crayford
2018-08-14 00:26:20 UTC
Permalink
Just out of interest why do you want to use Metal/C and not Regular C?
Post by Farley, Peter x23353
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.
Peter
-----Original Message-----
Sent: Monday, August 13, 2018 6:10 PM
Subject: Re: Using the Binder API and MetalC
... for future maintainability it sure would be nice if IBM split the /usr/include/__iew_api.h into two parts - Data definitions and function prototypes.
Or create two new header files for each and make /usr/include/__iew_api.h just #include the two new headers to preserve the current functionality.
Or. conditional compilation. Might there already be a feature test macro for MetalC?
--
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-08-14 17:14:03 UTC
Permalink
Post by Farley, Peter x23353
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.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2018-08-14 18:52:07 UTC
Permalink
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-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Tuesday, August 14, 2018 1:14 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Using the Binder API and MetalC
Post by Farley, Peter x23353
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Kirk Wolf
2018-08-14 19:21:22 UTC
Permalink
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 <
Post by Farley, Peter x23353
__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-----
Behalf Of Paul Gilmartin
Sent: Tuesday, August 14, 2018 1:14 PM
Subject: Re: Using the Binder API and MetalC
Post by Farley, Peter x23353
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.
Post by Farley, Peter x23353
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2018-08-14 19:52:59 UTC
Permalink
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-***@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf
Sent: Tuesday, August 14, 2018 3:21 PM
To: IBM-***@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.
Post by Farley, Peter x23353
__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-----
On Behalf Of Paul Gilmartin
Sent: Tuesday, August 14, 2018 1:14 PM
Subject: Re: Using the Binder API and MetalC
Post by Farley, Peter x23353
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.
Post by Farley, Peter x23353
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Thomas David Rivers
2018-08-14 21:29:41 UTC
Permalink
Post by Kirk Wolf
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.
Not to particularly quote Kirk, but just to add to the thread.

We didn't have too much trouble just looking at the documented
interfaces and producing the structures, etc... for Dignus Systems/C
programs
to use the binder interface.

Then, we just wrote a var-args function to invoke the IEWBIND
interface (even works in 64-bit mode.) You don't really need to use
the DLLs, you can just LOAD the IEWBIND module and invoke
the entry point returned from the LOAD with the proper code
number for the function and the proper arguments.

It is _slightly_ klunky, because we didn't need much, so the first
parm to the var-args function is the number of arguments, followed
by the IEWBIND function code, followed by the IEWBIND arguments
for that function... You _could_ get a lot fancier with C wrappers
for all of the functions, etc... which I suppose is what IBM did
in the LE DLL.

The actual IEWBIND interface is just a normal system interface,
no LE required.

For example, the code to start the session with the binder is:

...
val = 0x00004040;
code = (IEWBIND_STARTD << 16 | IEWBIND_VERSION);
call_iewbind(8, &code, &retcode, &rsncode,
&binder_token, fl, el, ol &val);
if(rsncode != 0) {
...

Depending on what interfaces you need to use, there's not a lot
to it once you get everything set-up.

I'm sure something similar in metal-C would work...

- Dave Rivers -
--
***@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
Steve Smith
2018-08-14 22:34:25 UTC
Permalink
I would like to reiterate David Crawford's question: why use Metal C
instead of the complete C?

Metal C is intended for writing exits and small routines where full
functionality isn't needed. It is a crippled C environment, and while you
may enjoy pushing it to its limits and beyond, you should at least be able
to articulate your reason for doing so.

For full disclosure, I have plenty of experience with Metal C being used...
just because somebody wanted to.

Something tells me that if IBM had called it C-lite, or Basic C, it would
have stayed in its place.

sas
Post by Thomas David Rivers
...
I'm sure something similar in metal-C would work...
- Dave Rivers -
--
Get your mainframe programming tools at http://www.dignus.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2018-08-15 00:11:39 UTC
Permalink
For the archives, I have replied privately to Steve and David on their question, as I am not in a position to discuss it publicly.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Steve Smith
Sent: Tuesday, August 14, 2018 6:34 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Using the Binder API and MetalC

I would like to reiterate David Crawford's question: why use Metal C instead of the complete C?

Metal C is intended for writing exits and small routines where full functionality isn't needed. It is a crippled C environment, and while you may enjoy pushing it to its limits and beyond, you should at least be able to articulate your reason for doing so.

For full disclosure, I have plenty of experience with Metal C being used...
just because somebody wanted to.

Something tells me that if IBM had called it C-lite, or Basic C, it would have stayed in its place.

sas
Post by Thomas David Rivers
...
I'm sure something similar in metal-C would work...
- Dave Rivers -
--

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
David Crayford
2018-08-15 03:35:15 UTC
Permalink
Post by Steve Smith
I would like to reiterate David Crawford's question: why use Metal C
instead of the complete C?
That would be Crayford :)
Post by Steve Smith
Metal C is intended for writing exits and small routines where full
functionality isn't needed. It is a crippled C environment, and while you
may enjoy pushing it to its limits and beyond, you should at least be able
to articulate your reason for doing so.
The interesting thing about Metal/C is the ability to do AR mode
programming using __far pointers which makes it suitable for low level
cross-memory
applications. I would suggest most of the heavy users of Metal/C are
vendors who develop systems software.  We still use assembler for that
stuff because
we have lots of excellent assembler programmers who are not inclined to
learn a new language. They all acknowledge that the Metal/C optimizer
generates
more efficient code then the can.
Post by Steve Smith
For full disclosure, I have plenty of experience with Metal C being used...
just because somebody wanted to.
I agree. I get the impression that some people use Metal/C just for the
sake of it or because they think it's cool. I stumbled across an SMF
formatting routine [1] from IBM that uses
Metal/C and I see no reason why it wasn't written in LE C. Why bother
inlining assembly to use QSAM macros when you can just use stdio fopen()
etc and not
have to worry about DCBs and getting storage below the line?

[1] https://github.com/IBM/IBM-Z-zOS/tree/master/SMF-Tools/SMF84Formatter
Post by Steve Smith
Something tells me that if IBM had called it C-lite, or Basic C, it would
have stayed in its place.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-08-15 14:06:30 UTC
Permalink
Apologies, Mr. Crayford :-)

z/OS is an interesting environment these days. There are a lot of options
in using C, Metal C, in-line assembler, assembler subroutines, or Metal C
subroutines from assembler. It's great to learn these, and learn them well
enough to choose wisely in organizing your programs.

sas
Post by David Crayford
Post by Steve Smith
I would like to reiterate David Crawford's question: why use Metal C
instead of the complete C?
That would be Crayford :)
Metal C is intended for writing exits and small routines where full
Post by Steve Smith
functionality isn't needed. It is a crippled C environment, and while you
may enjoy pushing it to its limits and beyond, you should at least be able
to articulate your reason for doing so.
The interesting thing about Metal/C is the ability to do AR mode
programming using __far pointers which makes it suitable for low level
cross-memory
applications. I would suggest most of the heavy users of Metal/C are
vendors who develop systems software. We still use assembler for that
stuff because
we have lots of excellent assembler programmers who are not inclined to
learn a new language. They all acknowledge that the Metal/C optimizer
generates
more efficient code then the can.
Post by Steve Smith
For full disclosure, I have plenty of experience with Metal C being used...
just because somebody wanted to.
I agree. I get the impression that some people use Metal/C just for the
sake of it or because they think it's cool. I stumbled across an SMF
formatting routine [1] from IBM that uses
Metal/C and I see no reason why it wasn't written in LE C. Why bother
inlining assembly to use QSAM macros when you can just use stdio fopen()
etc and not
have to worry about DCBs and getting storage below the line?
[1] https://github.com/IBM/IBM-Z-zOS/tree/master/SMF-Tools/SMF84Formatter
Something tells me that if IBM had called it C-lite, or Basic C, it would
Post by Steve Smith
have stayed in its place.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Harminc
2018-08-15 00:34:04 UTC
Permalink
Post by Thomas David Rivers
The actual IEWBIND interface is just a normal system interface,
no LE required.
...
val = 0x00004040;
code = (IEWBIND_STARTD << 16 | IEWBIND_VERSION);
call_iewbind(8, &code, &retcode, &rsncode,
&binder_token, fl, el, ol &val);
if(rsncode != 0) {
...
Depending on what interfaces you need to use, there's not a lot
to it once you get everything set-up.
I'm sure something similar in metal-C would work...
Indeed. A good many years ago (and long before the C interface
existed) I realized that it's quite possible to invoke IEWBIND from
REXX using Address LINKPGM. Not efficient, but it can be useful for
making little tools such as an eyecatcher analyzer for non-standard
modules.

Tony H.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2018-08-15 17:18:32 UTC
Permalink
<snip>
for future maintainability it sure would be nice if IBM split the
/usr/include/__iew_api.h into two parts - Data definitions and function
prototypes.
</snip>

OK, I'll bite.

Why is it important to separate the data from the function prototype?
Isn't the existing one syntactically correct? It might not be usable in
Metal C, but does its presence cause you harm?

Could you use #define to "change" the name to something else if you needed
a different name?

And, out of curiosity, do you have a requirement to avoid an LE runtime
for whatever you are doing here? Metal C is intended to solve a problem,
it is not intended to let you do everything you can do in C.

Perhaps what you really want is, in addition to what is there, a function
prototype that would let you provide the target address (e.g.,
iewxxxx_byaddr). You would have to get that address (such as by LOAD
through __asm). That pre-supposes that the target routine actually
supports a call using a "standard" parameter list which it sounds like the
binder API's do.

If an additional function prototype would help, that would be a reasonable
thing to ask for.

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2018-08-16 15:33:26 UTC
Permalink
Peter,

(Good name by the way ... :) It is not important to separate the data from the prototypes, that was just one method to achieve the desired end result - the ability to use the __iew_api.h C language data definitions in a MetalC program where one cannot use the predefined C language API functions or their prototypes.

The problem is that in MetalC with the NOLONGNAM<E default those function prototype names result in the compiler trying to generate "duplicate external names" (the first 8 characters of many of the function prototype names are identical). Using option LONGNAME is not an option because that requires GOFF-format output from the assembler and that means that all separately compiled subroutines must also be compiled with LONGNAME and GOFF in the assembler step, and that creates its own set of different problems, like how the heck does one link all of them together and get a successful executable out of it. I plead ignorance of GOFF and the processes to use it successfully, but my education in that area is sorely lacking. Mea culpa.

Anyway, in MetalC those predefined C language API functions aren't useable anyway because the executables they define are packaged in a DLL, which I suspect is very difficult to set up to use in MetalC, if it can be done at all.

Yes, one could use "#define" to "adjust" the predefined function prototype names so that they are all unique in the first 8 characters, but that seems like a lot of trouble (there are quite a few function names) for a set of routines that will not and cannot (easily) be used in the MetalC environment.

So in MetalC it is possible to use the data definitions packaged into __iew_api.h when processing the returned data from the binder API but it is not possible to use any of the predefined function prototypes to access the API itself.

However, in MetalC it is quite easy to use the assembler macro IEWBIND to actually invoke the binder API functions, just like an assembler program would do. But rather than use the assembler data definitions, MetalC can use the C language data area definitions from the API header to access the returned binder data.

It would be very convenient to have the Binder API header notice that the XLC compiler option METAL is turned on (feature test macro __IBM_METAL_ is DEFINEd) and simply bypass the predefined function prototype definitions entirely, since they are unusable in MetalC anyway. Or any other method which achieves the same end result, I would not want to limit IBM's innovation in solving the problem.

As for reasons not to use LE C, as I stated in an earlier reply in this thread I am not in a position to discuss it publicly.

I am a little confused by the several questions in this thread which seem to imply that using MetalC instead of LE C for accessing the Binder API is somehow beyond the pale of reasonableness. Would these questions would be asked if the thread was about using assembler to access and use the data from the binder API? If not, why is using MetalC (which after all has been touted as the "smart" assembler replacement for the next generation of programmers) to access and use the binder API data seem to be a problem?

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Peter Relson
Sent: Wednesday, August 15, 2018 1:18 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Using the Binder API and MetalC

<snip>
for future maintainability it sure would be nice if IBM split the /usr/include/__iew_api.h into two parts - Data definitions and function prototypes.
</snip>

OK, I'll bite.

Why is it important to separate the data from the function prototype?
Isn't the existing one syntactically correct? It might not be usable in Metal C, but does its presence cause you harm?

Could you use #define to "change" the name to something else if you needed a different name?

And, out of curiosity, do you have a requirement to avoid an LE runtime for whatever you are doing here? Metal C is intended to solve a problem, it is not intended to let you do everything you can do in C.

Perhaps what you really want is, in addition to what is there, a function prototype that would let you provide the target address (e.g., iewxxxx_byaddr). You would have to get that address (such as by LOAD through __asm). That pre-supposes that the target routine actually supports a call using a "standard" parameter list which it sounds like the binder API's do.

If an additional function prototype would help, that would be a reasonable thing to ask for.

Peter Relson
z/OS Core Technology Design
--


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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-08-16 15:55:49 UTC
Permalink
Dumb question: why NOT use real C where all those problems go away?



CharlesSent from a mobile; please excuse the brevity.
-------- Original message --------From: "Farley, Peter x23353" <***@BROADRIDGE.COM> Date: 8/16/18 10:33 AM (GMT-06:00) To: IBM-***@LISTSERV.UA.EDU Subject: Re: Using the Binder API and MetalC
Peter,

(Good name by the way ... :)  It is not important to separate the data from the prototypes, that was just one method to achieve the desired end result - the ability to use the __iew_api.h C language data definitions in a MetalC program where one cannot use the predefined C language API functions or their prototypes.

The problem is that in MetalC with the NOLONGNAM<E default those function prototype names result in the compiler trying to generate "duplicate external names" (the first 8 characters of many of the function prototype names are identical).  Using option LONGNAME is not an option because that requires GOFF-format output from the assembler and that means that all separately compiled subroutines must also be compiled with LONGNAME and GOFF in the assembler step, and that creates its own set of different problems, like how the heck does one link all of them together and get a successful executable out of it.  I plead ignorance of GOFF and the processes to use it successfully, but my education in that area is sorely lacking.  Mea culpa.

Anyway, in MetalC those predefined C language API functions aren't useable anyway because the executables they define are packaged in a DLL, which I suspect is very difficult to set up to use in MetalC, if it can be done at all.

Yes, one could use "#define" to "adjust" the predefined function prototype names so that they are all unique in the first 8 characters, but that seems like a lot of trouble (there are quite a few function names) for a set of routines that will not and cannot (easily) be used in the MetalC environment.

So in MetalC it is possible to use the data definitions packaged into __iew_api.h when processing the returned data from the binder API but it is not possible to use any of the predefined function prototypes to access the API itself.

However, in MetalC it is quite easy to use the assembler macro IEWBIND to actually invoke the binder API functions, just like an assembler program would do.  But rather than use the assembler data definitions, MetalC can use the C language data area definitions from the API header to access the returned binder data.

It would be very convenient to have the Binder API header notice that the XLC compiler option METAL is turned on (feature test macro __IBM_METAL_ is DEFINEd) and simply bypass the predefined function prototype definitions entirely, since they are unusable in MetalC anyway.  Or any other method which achieves the same end result, I would not want to limit IBM's innovation in solving the problem.

As for reasons not to use LE C, as I stated in an earlier reply in this thread I am not in a position to discuss it publicly.

I am a little confused by the several questions in this thread which seem to imply that using MetalC instead of LE C for accessing the Binder API is somehow beyond the pale of reasonableness.  Would these questions would be asked if the thread was about using assembler to access and use the data from the binder API?  If not, why is using MetalC (which after all has been touted as the "smart" assembler replacement for the next generation of programmers) to access and use the binder API data seem to be a problem?

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Peter Relson
Sent: Wednesday, August 15, 2018 1:18 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Using the Binder API and MetalC

<snip>
for future maintainability it sure would be nice if IBM split the /usr/include/__iew_api.h into two parts - Data definitions and function prototypes.
</snip>

OK, I'll bite.

Why is it important to separate the data from the function prototype?
Isn't the existing one syntactically correct? It might not be usable in Metal C, but does its presence  cause you harm?

Could you use #define to "change" the name to something else if you needed a different name?

And, out of curiosity, do you have a requirement to avoid an LE runtime for whatever you are doing here? Metal C is intended to solve a problem, it is not intended to let you do everything you can do in C.

Perhaps what you really want is, in addition to what is there, a function prototype that would let you provide the target address (e.g., iewxxxx_byaddr). You would have to get that address (such as by LOAD through __asm).  That pre-supposes that the target routine actually supports a call using a "standard" parameter list which it sounds like the binder API's do.

If an additional function prototype would help, that would be a reasonable thing to ask for.

Peter Relson
z/OS Core Technology Design
--


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 ***@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-08-16 16:11:11 UTC
Permalink
Metal C is an alternative to assembler in some situations, particularly
where the overhead of setting up LE is a problem, and also not needed.

If you want to use it as an "assembler replacement", then you'll need to
avoid pulling in header files generated for LE C.

If you want to use Metal C, then you live with its restrictions and
limitations. IBM won't and can't make it work just like real C.

And btw, you didn't answer Peter Relson's question: "... does its presence
cause you harm? "

sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2018-08-16 16:25:08 UTC
Permalink
Yes the binder API header as coded does cause harm when included in a MetalC program. Below is the result of including the binder API header as provided by IBM:

ERROR CCN3244 /usr/include/__iew_api.h:659 External variable __IEW_GE cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:658 External variable __IEW_GE cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:657 External variable __IEW_GE cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:588 External variable __IEW_GE cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:583 External variable __IEW_GE cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:579 External variable __IEW_GE cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:701 External variable __IEW_FD cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:699 External variable __IEW_FD cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:698 External variable __IEW_FD cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:697 External variable __IEW_FD cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:695 External variable __IEW_FD cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:690 External variable __IEW_FD cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:687 External variable __IEW_FD cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:685 External variable __IEW_FD cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:683 External variable __IEW_FD cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:680 External variable __IEW_FD cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:678 External variable __IEW_FD cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:675 External variable __IEW_FD cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:672 External variable __IEW_FD cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:670 External variable __IEW_FD cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:661 External variable __IEW_SE cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:644 External variable __IEW_SE cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:638 External variable __IEW_RE cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:613 External variable __IEW_IN cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:610 External variable __IEW_IN cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:607 External variable __IEW_IN cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:604 External variable __IEW_IN cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:600 External variable __IEW_IN cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:561 External variable __IEW_AL cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:548 External variable __IEW_AL cannot be redefined.
ERROR CCN3244 /usr/include/__iew_api.h:530 External variable __IEW_AD cannot be redefined.
CCN0793(I) Compilation failed for file //'TSOUSER.TEST.CSRC(TESTBIND)'. Object file not created.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Steve Smith
Sent: Thursday, August 16, 2018 12:11 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Using the Binder API and MetalC

Metal C is an alternative to assembler in some situations, particularly where the overhead of setting up LE is a problem, and also not needed.

If you want to use it as an "assembler replacement", then you'll need to avoid pulling in header files generated for LE C.

If you want to use Metal C, then you live with its restrictions and limitations. IBM won't and can't make it work just like real C.

And btw, you didn't answer Peter Relson's question: "... does its presence cause you harm? "

--


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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Barry Lichtenstein
2018-08-21 14:20:44 UTC
Permalink
Strictly as a circumvention, knowing that you are not actually going to call these functions, I want to make sure you know you could use the XL C/C++ SUPPRESS option: SUPPRESS(CCN3244)
Post by Farley, Peter x23353
Yes the binder API header as coded does cause harm when included in a MetalC program.
ERROR CCN3244 /usr/include/__iew_api.h:659 External variable __IEW_GE cannot be redefined.
. . .
ERROR CCN3244 /usr/include/__iew_api.h:530 External variable __IEW_AD cannot be redefined.
CCN0793(I) Compilation failed for file //'TSOUSER.TEST.CSRC(TESTBIND)'. Object file not created.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...