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.


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: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

Reply via email to