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

Reply via email to