On Jan 26, 2016, at 4:05 AM, Bill Woodger wrote:
Thanks Peter Farley and Don Poitras. I last used listserv in about
1999. Wow I thought, they've got a gui now. Err, no. So I
subscribed with the message in the subject. Hah. Nope. They've
changed that bit. And making another attempt to get a post on the
list itself...
I don't think the Binary Optimizer was intended as an amelioration
for clients concerned about moving to V5 but wanting the
performance boost from the latest processors.
It comes from IBM Research. The first I saw of it was in a LinkedIn
group in September 2013, and the Developer Works article linked-to
there stated:
"This tool can optimize program modules generated by the following
COBOL compilers:
COBOL for OS/390 & VM V2
Enterprise COBOL for z/OS v3
Enterprise COBOL for z/OS v4
The tool runs on z/OS version 1.11 or later.
The tool can generate program modules for z10, z196, or zEC12."
Given the range of compilers (and OSes) and target machines,
greatly increasing development and support complexity, it is no
surprise that there has been rationalisation.
Whether how it will be used (likely) is coincidence or a later
design I don't know.
It is not a panacea. From discussion on that group at the time with
IBM's Marcel Mitran:
"The research team has been collaborating very closely with the
COBOL compiler team. In fact several of the optimizations used in
the binary optimizer were co-developed with the compiler team... In
general, I would expect the binary optimizer improvement to be less
than that of the compiler. A fully-enabled and optimizing compiler
like COBOL 5.1 should always be the preferred approach to
optimizing applications. The binary optimizer is really only meant
to address concerns when a recompile is not feasible."
Their current documented suggestions for the situations where the
Binary Optimizer could be used bear that out.
Use case
IBM Automatic Binary Optimizer for z/OS
Significant performance improvement without requiring source,
migration, or options tuning
Interoperability and legacy compatibility (eg, support for PDS and
old Enterprise COBOL)
No need to downgrade ARCH setting to match disaster recovery machine
Latest IBM COBOL compilers
New COBOL development
Maintenance on existing COBOL programs
Maximum performance improvement (source, migration, and options
tuning required)
Yes, it does mention the PDS thing. No, it doesn't work on V5
programs.
Enterprise COBOL generating Program Objects is not new with V5. It
is new that all code generated from V5 must now be Program Objects.
It is central and indivisible in V5. It is part of the planning for
the development of V5 and beyond. There's no going back with the
new compiler.
IMO IBM blew it on this alone and will loose customers. Maybe even
the account I am helping out now. At best it was a short sighted
attempt to get people to buy new hardware. In case IBM didn't realize
money is extremely tight and bullying them is not a good way to make
friends.
I will help my client out on figuring a way around this financial
bullying tactic. If asked I will explain IBM is no longer in the
business of working for the small business.
It might be IBM has done what MS did with XP. Hint people (many) are
still running XP.
Ed
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN