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. Peter P.S. -- To Bill Woodger: I don't know how other COBOL programmers work, but I *always* review the compiler warnings, and strive to make my compilations warning-free. I don't always succeed (data area copy books that define smaller areas over larger ones and debugging paragraphs that are not commented out are particular nuisances), but I do try. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Timothy Sipples Sent: Friday, October 14, 2016 2:30 AM To: [email protected] Subject: Re: ABO Automatic Binary Optimizer <Snipped> With all that said, one has to be smart about when, where, how, and how much to test. Bill Woodger reminded me of an important fact, that if you're not smart about testing and you're just running "big" tests over and over to tick checkboxes, even when it makes little or no sense, then you're not actually testing well either. You're very likely missing genuine risks. Literally nobody wins if you've got an expensive, bloated testing regime that isn't actually testing what you should be testing in 2016 (and beyond). There are also many cases when business users simply throw up their hands and declare "No thank you; I can't afford to wait 68 days for your testing program to complete," and they shop elsewhere for their IT services. My friends and colleagues, we must always be *reasonable* and adaptable, else we're lost at sea. And it's simply unreasonable to treat ABO optimizations the same for testing purposes as source code changes and recompiles. The source code doesn't change! The correct ABO testing effort answer should be something more than zero and something less than what's ordinarily advisable for a "typical" source code change/recompile trip. Please consult with ABO technical experts to help decide where precisely that "in between" should be given your particular environment and applications. -- 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 [email protected] with the message: INFO IBM-MAIN
