@Janet, I have no personal experience with this exact problem, but from what I do know and what others have written here, if you wish to market a C/C++-callable API-type product in object or assembler source code form, you will have to at least consider shipping not two but THREE implementations:
1. Non-XPLINK (31-bit) 2. XPLINK (31-bit) 3. XPLINK-64 Note I say "consider." You could possibly shortcut the above a little: - If the routine is not called frequently (an initialization routine, for example) you could combine 1 and 2 above and use a #pragma to tell C/C++ what you have done. It should not be called frequently because there is said to be a significant performance penalty. - You might be able to solve 3 with a bridge routine rather than a full API implementation, depending on the characteristics of the function. The bridge routine would have to set up the proper linkage including a save area below the bar, copy any above-the-bar parameters below the bar, issue SAM31, and call either 1 or 2. On return it would have to issue SAM64, unwind the linkage, and return. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Janet Graff Sent: Monday, August 29, 2016 8:46 AM To: [email protected] Subject: Re: Dump in 64 bit mode "Storage around GPR2 is invalid." Charles, It doesn't appear that the register conventions for XPLINK and non-XPLINK are compatible. If one were marketing an Assembler API would you have to deliver two versions? One XPLINK and one non-XPLINK? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
