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 |
k...@ntrs.com
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:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Lizette Koehler
> Sent: Wednesday, October 12, 2016 11:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Norman Hollander on Desertwiz
> > Sent: Wednesday, October 12, 2016 9:26 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > 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:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Charles Mills
> > Sent: Wednesday, October 12, 2016 8:48 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > 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:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Lopez, Sharon
> > Sent: Wednesday, October 12, 2016 7:51 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > 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
> 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

Reply via email to