V6.3 introduced 64-bit (batch) support. We don't intend to take advantage of this yet, if ever. Especially with the requirement to support two sets of "shared" subroutines if we were to do so. Honestly, it seems like that wouldn't be that difficult; just compile the program twice in to two different "load" libraries; but at this point we've not run in to any limitations that would cause us to need 64-bit programs. And until IMS and embeded DB2 are supported in 64-bit environments it's pretty much a no-go.
Anyway, what you recommend is pretty much what we do now. The developer specifies what compiler version to use for any particular program. It's then tested and implemented with that version. Sounds like you are recommending we continue with this methodology. FWIW, I am the senior developer that would do much of the "trail run" for this new version. Frank ________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Farley, Peter x23353 <peter.far...@broadridge.com> Sent: Monday, January 13, 2020 5:49 PM To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: Migrating to new compiler release Is it V6.3 that introduces the capability to generate 64-bit executables. Or is that already available in V6.2? If V6.3 introduces the ability to generate 64-bit executables I would argue (even as a COBOL developer) for a transition period where V6.3 was "available but not standard", with an application team or two tasked to test their next release of application code using the new version and other teams constrained to keep using the older release. Maybe for two application maintenance cycles if one is feeling particularly careful. I would also put automation in place to prevent accidental use of the 64-bit executable compiler/linker option(s) unless specially authorized and with a design review validated with appropriate input from both the systems programming and the capacity teams. Even if it isn't V6.3 that makes 64-bit executables possible, I would take the "available but not standard" route for at least one application development cycle, and let your most senior technical application developers play with it to see if they can find anything to worry about. Personally, I'd rather be safe than sorry, and I suspect that most employers would usually insist on it. Peter -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Charles Mills Sent: Monday, January 13, 2020 6:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release Caution and backups and fallback strategies are always good, but I don't think there is much relationship between *running* a COBOL version X program and having the *compiler* version Y installed. I believe all of the runtime is part of LE, not the compiler, and compatibility from VS COBOL II (if I recall correctly) to current C++, PL/I and COBOL is what LE does for a living. Not always perfectly, but that is what APARs and PTFs are for. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Monday, January 13, 2020 3:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Migrating to new compiler release I was wondering what "methodologies" shops have for migrating to a new "release" within the same "version" of a compiler. Specifically, we currently have Enterprise COBOL 6.2 (V6 R2) and 6.3 is now available. Our systems group asked if we just wanted to "replace" 6.2 with 6.3. I'm a bit wary especially of a program having been compiled with V6.2 but then implemented with V6.3. Am I over thinking this, perhaps because of the large difference in the compiler from V4 to V5? What is the likelihood of a compiler bug being introduced in V6.3 for code that worked in V6.2? Perhaps very, very little. But I'd still like to hear thoughts and opinions. For what its worth, along with 6.2 we still have 4.2 and 5.2 installed. But we really should only be using 6.2 at this point any time a program is recompiled. Anyway, up to this point we've always made sure that the production compile is done with the same version/release as all of the testing. Thanks, Frank 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
