The procedure Peter describes has clear benefits, but the ability to 
incorporate one CEC at a time into an existing complex is IMO something of a 
luxury. It means having an entirely new separate of cables, power connections, 
and replication of all other necessaries. It means new/changed connections for 
SNA and TCP/IP plus all the software definitions required to support them. Then 
at some later time the old CEC has to be extricated from the complex without 

If someone proposed this procedure in our shop, I would probably argue that the 
risk to operational stability would be greater than the risk of an old 
fashioned push-pull. Not to mention cost.

J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Friday, October 14, 2016 10:00 AM
Subject: (External):Re: ABO Automatic Binary Optimizer

I don’t know how other installations perform processor model upgrades, but our 
facilities manager moves in one new processor (CEC) at a time on a weekend 
during an extended maintenance window and activates only the development/QA 
LPAR's on it for at least a week (sometimes more) of "active use" of the new 
model before migrating production LPAR's to the new model.  Remaining CEC's are 
migrated in similar fashion over a period of months.

A "live" regression test, if you will, with only Development/QA LPAR's affected 
by any issues.  I suppose a similar procedure could work for ABO translations, 
but I suspect that hardware change is "different" from the company's 
perspective, not under full company control if you will.  Individual programs 
*are* under full company control and thus subject to the regression test rules.

I don’t know how we handle microcode updates, so I can't comment accurately on 
that, but I suspect it is done one CEC at a time with backout procedures in 
place in case of issues.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, October 14, 2016 12:31 PM
Subject: Re: ABO Automatic Binary Optimizer

On Fri, 14 Oct 2016 11:29:46 -0400, Farley, Peter x23353 wrote:

>You missed two crucial issues:
>1. Auditors don't believe in "verification" and management requires audits to 
>pass.  IT does not control auditors (quite the reverse in fact).  And we lowly 
>programmers have no input to auditors at all.
>2. There is no existing independent verification tool for a company to use on 
>ABO's output.  And if someone creates one, it has to be from a company OTHER 
>than IBM so that IBM's ABO results are independently verifiable.
>"Smart" testing is of course a valid and desirable goal, but lacking an 
>existing *independent* verification tool there is no option but full 
>regression testing.  Manual verification is not reasonable or cost effective, 
>especially for very large programs and program suites.
>And again, I am not trashing ABO, which on its face is an amazing tool BUT it 
>changes object code.  Lacking independent automated verification, in any sane 
>definition of a program life cycle system that is a change that requires full 
>regression testing.
Do the above apply likewise to moving to a different processor model, or even 
to a microcode upgrade?

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to with the message: INFO IBM-MAIN

Reply via email to