Jumping in a little late here, but AMODE 64 for *code* is not necessarily the need for most business purposes. AMODE 64 for *data* is the need that I perceive as primary. I would be well satisfied if 64-bit data storage could be used transparently even with code running only in 31-bit storage.
There are many business processes that will benefit from the ability to hold far more data in memory than is now easily possible in current HLL implementations except C/C++. For example: 1. Business processes that rely on ever-larger in-memory tables of characteristics that vary between customers when processing order cannot be performed in customer order 2. Transaction aggregation processes that must temporarily store in memory more and more items per processing unit as the web-world transaction volume grows exponentially 3. Despite the continuously increasing speed and substantial external data caching of I/O devices, the need for ever-larger in-memory I/O buffer caches is growing because the processor speeds have increased even more dramatically, and business processes that can use direct I/O buffer addressing (unfortunately not usually supported by existing HLL file semantics) will benefit substantially from being able to directly address cached buffers stored above the bar 4. As some others have also mentioned, interfacing with Java (or any other JVM-based language) processes passing data from 64-bit storage for HLL business processing will be a growing requirement Today such business processes are limited by the 31-bit addressing constraint of the non-C/C++ HLL compilers to using assembler interfaces for large-memory needs. As there are fewer and fewer of us in active service who are comfortable and competent writing and maintaining such interfaces, the need for all of the available HLL's to support 64-bit addressing for data should be clear. 64-bit Metal C is an alternative to large-memory assembler interfaces, but this is also not a competency that seems to be widely available. Even after 64-bit data addressing support is available, of course, Bernd is correct that the changeover of already-developed internal data structures to support larger pointer sizes will be a serious project for any business to undertake, and not one to be achieved overnight. The ability to use direct pointer arithmetic using HLL semantics instead of needing to use integer redefinitions of pointers to perform pointer arithmetic would be quite helpful in such data restructuring projects. HTH Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Ross Sent: Wednesday, January 14, 2015 7:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Compile COBOL Programs In 64 Bit. >Hi,I am looking for COBOL compiler option to compile our COBOL programs in = >64 Bit mode.Please lead me if you have such a experience .The COBOL version= > is 4.2 on Z9 with z/OS 1.12. Best regardsManshadi AMODE 64 COBOL is still being worked on here at IBM. I (like the other poster) would like to know what you would do with AMODE 64 COBOL? Also, does everyone realize that AMODE 64 code will run slower than AMODE 31 code? We assume that AMODE 64 COBOL will be used for very specialized one-off cases to solve specific business problems, and that in general 99% of code will be compiled for AMODE 31 even after we ship AMODE 64 COBOL. Unlike AMODE 31, which we expected EVERYONE to move to (still waiting :-) we do not think very many users will need AMODE 64 in the next 10-15 years. We are gathering use cases and verifiable needs for AMODE 64 COBOL, so if you know of any, please SHARE! (get it? :-) Cheers, TomR >> COBOL is the Language of the Future! << ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
