Thanks for your comments and additions to the requirements for a good 64-bit COBOL implementation. My opinions about multiple versions are based on financial industry audit requirements - NOTHING gets into production without testing. Period. Hence a dual-compile (and that would be two separate compiles, as I seriously doubt that one compile step can or will ever produce two different object outputs) and dual binds becomes very burdensome for the development organization when you add in the required testing.
And the testing for shop-wide common subroutines is even more burdensome for a dual-compile implementation. In that case every application that uses the common modules has to be tested. We don't use IMS, only DB2, but obviously if mixed 31/64-bit calling is not permitted (or imposes severe performance penalties) both systems would require 64-bit interfaces along with the corresponding LE dynamic call interface. Not to mention the non-IBM database systems available from various ISV's (ADABAS, IDMS, etc.). Like you, we make extensive standardized use of dynamic CALL, and would also not look favorably on a DLL requirement. The developer training required to permit conversion to DLL-style linkage would prohibit that path. AFAIK there aren't many (any?) mainframe COBOL developers trained and experienced in creating or using COBOL DLL's. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Thursday, October 18, 2018 1:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit Related to this, we would require a 64-bit IMS DL/I interface and 64-bit CICS LE application support before even considering a migration to 64-bit. Well, I suppose we could leave the CICS programs 31-bit, but without IMS support for 64-bit modules it would be pretty much useless, as almost all of our core data is in IMS. ________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Frank Swarbrick <frank.swarbr...@outlook.com> Sent: Thursday, October 18, 2018 11:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit While I understand what you are saying, and mostly agree with it, I'm not sure I agree that having 31-bit and 64-bit versions of callable subroutines is a deal breaker. It seems to me that if the compiler could generate both 31-bit and 64-bit objects from the same compile step, and the shop could then just have two program binder steps going to two different libraries. Would there be double the testing? Maybe at first until you get comfortable with the process, but after that I don't see why you'd need to test both versions to the same degree. Maybe just a "smoke test" on the version you don't plan on using for the full test, but that's about it. That being said, there probably would be an initial "cost" of recompiling and testing all sub-routines as 64-bit. I imagine, if 31/64 calls are not allowed, you'd want to have a JOBLIB/STEPLIB that contains only 31-bit modules for 31-bit run units and 64-bit modules for 64-bit run units. My personal biggest concern, regardless of whether or not there can be combined 31/64 bit run units, is if there ends up being some sort of requirement for DLL calls. We use dynamic calls exclusively for COBOL to COBOL, and while I am a fan of DLLs in theory I'd be wary of a lot of source code changes being required to "migrate" to DLL calls. Just one person's thoughts... Frank ________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Farley, Peter x23353 <peter.far...@broadridge.com> Sent: Wednesday, October 17, 2018 3:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit 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