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 disruption.
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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Farley, Peter x23353 Sent: Friday, October 14, 2016 10:00 AM To: [email protected] 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. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Friday, October 14, 2016 12:31 PM To: [email protected] Subject: Re: ABO Automatic Binary Optimizer On Fri, 14 Oct 2016 11:29:46 -0400, Farley, Peter x23353 wrote: >Timothy, > >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 [email protected] with the message: INFO IBM-MAIN
