+1
-- Peter Hunkeler Von: "Farley, Peter x23353" <peter.far...@broadridge.com> An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: COBOL 64bit Datum: 17.10.18, 23:29 The following is just my personal $0.02USD worth. I speak for myself only and not for my employer. Just like any other new version of the COBOL compiler, 64-bit addressing support must be able to be phased in, subroutine by subroutine. Forcing all subroutines in a main program to become 64-bit if any one of them becomes 64-bit is NOT acceptable. Neither is any serious performance impact acceptable in mixed 64-bit-plus-31-bit programs, no matter what the starting addressing mode may be. In other words, do NOT use XPLINK for 64-bit COBOL. Find a better way that is far more compatible with current static and dynamic calling conventions. For one specific example, many (if not most) large z/OS shops have shop-wide application subroutines for I/O processing of application-specific files which all or at least many different applications in the shop use when they need to access those files. If one application program needs or desires to be recompiled for 64-bit support, there is no way that the application-specific shop-wide subroutine can be allowed to be recompiled as 64-bit because then every other application in the shop would all have to be converted to 64-bit at the same time. That can't (and won't) happen. Keeping separate libraries and separately-compiled versions for 64-bit and 31-bit subroutines may seem like a solution, but it is a management and SDLC maintenance nightmare. COBOL V5+ forced shops to support PDSE libraries for production application executables, but forking that into new separate libraries for 31-bit and 64-bit is just not practical or feasible. Every application would then have to test and maintain 2 versions of every common subroutine that they own, and there are no resources available to support that level of work. Most of us are already running as fast as we can to stay in one place, with no time to spare for anything else. Piecemeal, phased recompilation must be supported, without any serious performance penalties for either the newly compiled 64-bit programs or for the remaining 31-bit programs that are used in the same main program. It is acceptable for all-64-bit programs to have "better" performance (FSVO "better"), but impacting current SLA's because one subroutine became 64-bit is NOT acceptable. SLA's are already far too tight with no slack available. IBM must not screw this up with impossible-to-implement-in-the-real-world conditions or performance penalties. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Kielstra Sent: Wednesday, October 17, 2018 4:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit EXTERNAL EMAIL It is only available in 31-bit. An interesting question to ask is: if it were available in 64-bit but mixing and matching 31- and 64-bit modules was not possible (i.e., you would have to recompile all modules in an application), would that be interesting? Or is it the case that it is vital to be able to selectively compile modules (in 64-bit mode) and mix and match? -- 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
