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
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.
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Timothy Sipples
Sent: Friday, October 14, 2016 2:30 AM
Subject: Re: ABO Automatic Binary Optimizer
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
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
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