In our experience the need for PDSE datasets was far from the only difficulty in migrating to COBOL V5 (and that really wasn't the hard part). Many compiles take drastically more CPU time as well as require more region. While this is documented we were stunned by the orders of magnitude. Compiles that had previously taken single digit CPU seconds suddenly needed minutes (this is on a z13). Similarly where a 4MB Region default had been adequate those compiles routinely failed; we were directed to specify 200MB but found even that frequently failed and threw up our hands and told everybody to use REGION=0 (personal peeve of mine). We also did find some incompatibilities for which we opened up PMR's and received APAR's.
Within the context of the thread topic, ABO . . . I discussed this quite a bit with my account team. Our developers are required to do regression testing on their changes - even if it is just recompiling with no source code changes. They initially argued (well, not initially, it went on way too long) that there's no need to do such testing when using ABO. Technically they may be right; technically one probably shouldn't have to do complete regression testing when recompiling the same source. None of that makes any difference if the stated requirement in the development standards they have to follow says they DO have to do that testing. Knowing that, then, they would be similarly required to do that testing for an ABO optimized module we questioned the benefit of licensing another product to do the same thing the compiler can do. Now, if there's a substantial amount of executing COBOL code that consumes a fair amount of resources AND the source is missing/unavailable then maybe ABO is in play - but that's not our situation. ________________________________________________________________________ _______ Karl S Huf | Senior Vice President | World Wide Technology 50 S LaSalle St, LQ-18, Chicago, IL 60603 | phone (312)630-6287 | [email protected] Please visit northerntrust.com CONFIDENTIALITY NOTICE: This communication is confidential, may be privileged and is meant only for the intended recipient. If you are not the intended recipient, please notify the sender ASAP and delete this message from your system. NTAC:3NS-20 P Please consider the environment before printing this e-mail. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Lizette Koehler > Sent: Wednesday, October 12, 2016 11:38 AM > To: [email protected] > Subject: Re: ABO Automatic Binary Optimizer > > The only difficulty in migration to Cobol V5 and above is the need for PDS/E > datasets. > > Since z/OS V2.2 is providing a way to not have to UPDATE all production JCL > with PDS/E datasets, that issue with migration, imo, is greatly reduced. > > So once z/OS V2.2 is installed, migration plans to COBOL V5 and above should > be able to begin. > > Lizette > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[email protected]] > > On Behalf Of Norman Hollander on Desertwiz > > Sent: Wednesday, October 12, 2016 9:26 AM > > To: [email protected] > > Subject: Re: ABO Automatic Binary Optimizer > > > > 2 Thoughts to consider: > > > > - ABO only runs on z/OS 2.1 and above > > - ABO creates a new load module that (IMHO) needs as much Q/A testing > > as compiling in the newest compiler. > > IIRC, back in the day, going to Enterprise COBOL, there was less than > > 8% of COBOL source that needed > > to be remediated. That is, certain COBOL verbs needed to be updated > > to new ones. Things like INSPECT > > may have been flagged. > > > > A good Life Cycle Management tool (did I say Endevor?) could help with > > an easy migration to a new compiler. > > You could try a minor application and see how difficult in may be... > > > > zN > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[email protected]] > > On Behalf Of Charles Mills > > Sent: Wednesday, October 12, 2016 8:48 AM > > To: [email protected] > > Subject: Re: ABO Automatic Binary Optimizer > > > > Nope. Agree 100% with what @Tom says. The ABO is not a source code > > migration tool, it is a compiler. Really -- a very weird compiler. > > Most compilers take source code in and produce object code out. The > > ABO is a compiler that takes object code in and produces object code > > out. What good is that? It takes System 370 object code in and produces z13 > object code out. > > > > Why is that useful? Because the speed gains in the last several > > generations of mainframe are not in clock/cycle speed. System 370 > > object code does not run any faster on a z13 than on a z10. The gains are in > new instructions. > > The same functionality as that S/370 object code expressed in z13 > > object code runs a lot faster. > > > > (Please, no quibbles. Many shortcuts and generalizations in the above. > > If I had been perfectly precise it would have read like a legal > > document. The general points are correct.) > > > > Charles > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[email protected]] > > On Behalf Of Lopez, Sharon > > Sent: Wednesday, October 12, 2016 7:51 AM > > To: [email protected] > > Subject: ABO Automatic Binary Optimizer > > > > Does anyone know if this product, Automatic Binary Optimizer, will > > actually migrate Cobol V4 to V6 for you? Our IBM reps are telling us > > that it will actually do the migration for you. Based on what I've > > read, it is a performance product and I didn't see that capability. > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
