I have just converted a large C program from 31-bit to 64-bit because MQ Series Version 8 now supports LP64. There are 28 modules and no Metal C code as this app runs on many different platforms. All called assembler subroutines, z/OS-only, are now AMODE 64 and a number do switches internally to AMODE 31 in order to call 3rd party software that is either RMODE 24 or 31 (because of old I/O, etc.) All this works fine at this point even loading and walking through AMODE 31 load modules that are just DSECTs with internal pointers to various control blocks. The DSECT modules are also 3rd party so we can't change them. Calling the executables via the assembler code requires you to use __ptr32 in the C code for the variables to be passed to the 3rd party code and then using only the 2nd word of each entry in the parm list passed to the AMODE 64 assembler routine for restructuring the parm list for the 3rd party software. So far this is working better than originally anticipated and was quite simple to implement. There were some odd changes to address the DSECT Load modules and internal blocks as the original code worked on z/OS AMODE 31 and zLinux, multiple UNIX environments, Wintel Linux and Windows in AMODE 64.
John T. Abell President International Software Products Tel: 800-295-7608 Ext: 224 International: 1-416-593-5578 Ext: 224 Fax: 800-295-7609 International: 1-416-593-5579 E-mail: [email protected] Web: www.ispinfo.com This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive on behalf of the named recipient), please contact the sender by reply email and delete all copies of this message. Also,email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Charles Mills Sent: Friday, October 17, 2014 5:19 PM To: [email protected] Subject: Re: 64bit These remarks of mine may produce some reactions ... I have not done any 64-bit work in C/C++, but the number of "this is not available in AMODE 64" and "this behaves differently in AMODE 64" notes would give me pause. I have a requirement/enhancement that would be perfect for above-the-bar from C++ but I am nervous about undertaking it that way for that reason. There seem to be in general so many unexpected interdependencies among various C/LE options. I needed to interface to the GSK encryption. That required POSIX(ON). All went well until final testing, when a stupid little utility program that was supposed to be loadable from COBOL suddenly was not. Why not? COBOL can't load a POSIX(ON) C program. Really? Really. In addition to this sort of gotcha be aware of the inherent/documented differences. In 32-bit C, for example, a uint and a size_t are the same thing -- you can pass & of a size_t to a method with uint * in its prototype; but in AMODE 64 C they are not the same thing and you cannot. Don't get me wrong. I love XLC. Could not do what I am doing without it. But AMODE 64 C gives me pause. I would love to hear that I am wrong. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Scott Ford Sent: Friday, October 17, 2014 1:55 PM To: [email protected] Subject: Re: 64bit Charles, The more I see the more I want/will convert the Cobol code to C or C++. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
