We got bit by that years ago too. IBM seems to be pretty good now with hold actions on COBOL PTF that requires a specific LE PTF to be available everywhere prior to the introduction of the Cobol PTF.
_____________________________________________________________________________________________________ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Jesse 1 Robinson Sent: Wednesday, January 15, 2020 1:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Here's another gotcha to worry about regardless of compiler version. It was a real problem, not hypothetical. We installed a new z/OS Server Pac that happened to include a new COBOL release: 4.2 to replace 4.1. As others have mentioned, the ancient practice here is to do *all* compiles on the development system, then migrate only load modules throughout the enterprise. We did some testing with 4.2 compiles on the production system ahead of time and found a bug in LE. The problem was not 4.2 per se but simply that prod was down level in maintenance. There was an LE PTF available, but it would have required a production IPL to implement. We could not just drop the new z/OS onto development until we had a chance to IPL production to install the LE fix beforehand, none of which was part of the rollout plan. The woeful tale goes on and on, but the experience is burned into bio-memory. Be cautious. Be very very cautious. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Frank Swarbrick Sent: Wednesday, January 15, 2020 10:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Migrating to new compiler release Yeah. We do have regressions tests, but it's not built in to change control itself. Perhaps something we should look in to enhancing. Thanks. ________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Jousma, David <000001a0403c5dc1-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, January 15, 2020 11:12 AM To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: Migrating to new compiler release We migrate source *and* executable into a controlled stage environment where the app folks are supposed to do one last round of tests. From there, its straight copy to all PROD locations. _____________________________________________________________________________________________________ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Michael Babcock Sent: Wednesday, January 15, 2020 1:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Migrating to new compiler release **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** You’ve got me there! I would think that chance is relatively small and wouldn’t worry about it. On Wed, Jan 15, 2020 at 12:08 PM Frank Swarbrick < frank.swarbr...@outlook.com> wrote: > Intentional differences, yes. Bug; probably not! 🙂 > > ________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on > behalf of Michael Babcock <bigironp...@gmail.com> > Sent: Wednesday, January 15, 2020 11:04 AM > To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU> > Subject: Re: Migrating to new compiler release > > Any difference should be documented in the migration guides I would think. > > On Tue, Jan 14, 2020 at 1:38 PM Frank Swarbrick < > frank.swarbr...@outlook.com> > wrote: > > > I understand that the runtime is part of LE, and is generally shared > > between versions (at least V5 and V6 seem to share the same runtime > > for many/most functions). Conceivably it's still possible that the > > code generated by a certain version of a compiler may have defects. > > Probably less likely if the code is in a pre-existing feature. > > > > My question has to do with the (probably slight) possibility that > > the > code > > generated by one compiler would be different, for the same > > statement, for another. > > > > ________________________________ > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on > > behalf of Charles Mills <charl...@mcn.org> > > Sent: Monday, January 13, 2020 4:54 PM > > To: IBM-MAIN@LISTSERV.UA.EDU <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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
