I found my approach below in the IBM documentation on my "day one" of C++/assembler integration. I have never done it any other way.
What you are doing is appealing. There is something annoyingly inefficient about a 32-bit pointer to a 32-bit copy of a 32-bit value. I don't think I ever pass shorts but I guess that would lead to a 32-bit pointer to a 32-bit copy of a 16-bit value, given C's integer promotion. (XPLINK is better IIRC.) Do you use EDCPRLG and EDCEPIL with your approach? BTW, with the "OS" linkage, 32-bit return values come back as you would expect in R15. 64-bit return values come back rather astonishingly in the low-order 32 bits of R15 (high word) and R0 (low word). Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Tuesday, February 6, 2018 11:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RDJFCB function in C++ On Tue, Feb 6, 2018 at 1:26 PM, Charles Mills <charl...@mcn.org> wrote: > e.g. > > #ifdef __MVS__ > extern "OS" { > #endif > void ABEND(const int code, const int reason); > int GETJESND(char JES_node[9]); > #ifdef __MVS__ > } > #endif > > Charles > ​Thanks! I now see where you're coming from by using the extern "OS" {...}. I will go into an internal three way argument over which is better to do: (1) Use the extern "OS" facility to use a historic OS calling sequence or (2) structure my HLASM code to have a C calling sequence. Most likely I'll decide "it depends" on what I think the usage will be. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
