This guy Peter certainly makes a convincing argument for 64 bit data storage addressing. Good info from the field and pretty hard for anyone in IBM to know about. Maybe Peter's points will be taken into consideration. Seems like it would behoove IBM to spend some to keep their mainframe customers happy. If they don't, I would love to write some C++ Service routines for 64 bit data storage manipulation by good ol' COBOL.... C++ and COBOL don't place nice together for passing data but that can be easily overcome.
JAO - Duf > On Jan 20, 2015, at 8:12 AM, "Farley, Peter x23353" > <peter.far...@broadridge.com> wrote: > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
