Thanks Norman, but as I am not a sysprog I am not involved in those types of changes. I/we depend on our facilities management team to handle those issues.
Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Norman Hollander on Desertwiz Sent: Friday, October 14, 2016 1:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ABO Automatic Binary Optimizer You should request the Hardware Buckets for microcode updates. Sometimes, there could be a necessary OS PTF to support/exploit new microcode. Is there a chance that microcode code cause a production problem? You know the answer... Can the update be backed out? Not always... -----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 To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, October 14, 2016 12:31 PM To: IBM-MAIN@LISTSERV.UA.EDU 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? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
