The question of 'how much testing with ABO' is entirely cultural. No technical expert can provide an answer satisfactory to all. At one end, you can argue for minimal testing because application code has not changed, only the executables. How many shops insist on extensive testing for updates to LE? That's the executable side of COBOL after all. We test for compiler changes but seldom if ever for LE PTFs or even what comes with the next z/OS.
At the other end you have to deal with application programmers' unease at changes outside their control. In my first IT job, I worked in an application unit that eschewed dynamic run-time loads by running a 'super link' that pulled in all available load modules to form a single large executable. They did not want any 'surprises' at run time. That was long ago, but I suspect that the same mentality still prevails in many shops. We haven't set off down the yellow-brick ABO road, so it's hard to gauge how much angst we'll actually have to overcome. I'm pretty sure it won't be trivial. . . 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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bill Woodger Sent: Sunday, March 26, 2017 8:17 AM To: [email protected] Subject: (External):Re: Migrating Cobol If you have very large programs and you want to optimise them to Level 1 or Level 2, then Enterprise COBOL V6.1 is your best bet. The optimiszer was re-written with 64-bit addressing and is now much more comfortable with large programs (which may just fail to compile with V5.2). V6.1 is now "continuous delivery". Meaning new functionality, not just fixes and retro-fitting, can and is being supplied by PTF. Consider use of the Automatic Binary Optimizer (ABO). This can allow your COBOL programs to benefit from z/ARCH instructions without needing to be recompiled. This can allow you to rework your planning. Biggest problem seems to have been the need for PDSE: no more loadmodules, now Program Objects, which must be in a PDSE. ABO again offers some extra flexibility by not requiring PDSE for all executables. IBM has done a lot of work over the last few months to reproduce V4.2 output where the results expected are "undefined" across all compilers, but have a specific outcome under a particular compiler. You could chose ABO for "everything" and V5/v6 for new development/maintenance (an incremental "migration") through to Big Bang, V5/V6-only, and devil take the hind-most. Or anything in between. ABO has not been around long, and V1.2 only since last November. ABO gives you some new ways to do migration, but be aware that there are still discussions (including on this list) as to how much testing is required for an ABO over a recompile. Ask your friendly IBM rep if you can talk to the ABO people in Markham about your specific site :-) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
