You do not comprehend the depth of the fear of failure in large, audited 
business organizations.

Also the "verification" you propose that we use for ABO output has no 
programmed tool yet to perform the verification automatically - IEBIBALL is the 
only current tool available, and that is notoriously inefficient and 
error-prone.  Do you expect each ABO client to "roll their own" automated 
verification tool?  IEBIBALL a 10000+ line COBOL program assembler listing 
(option LIST) against the list produced by ABO?  I don't think so.

I am not saying ABO is a bad tool, only that it must be considered as a change 
like any other actual source change in order to allay natural and substantial 
concerns in any large organization.  Like the OPT compiler option, if the 
tested version does not use the option (or does not use ABO before testing) 
then it was not tested at all and is not "ready for QA".

No auditor I have ever encountered will tell you otherwise.  I wouldn’t buy it 
either if I were an auditor.

Careful is not wasteful.  Careful saves jobs and companies.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Thursday, October 13, 2016 2:31 PM
Subject: Re: ABO Automatic Binary Optimizer


For a recompile, where the program is not expected to have changed even one 
iota, a regression-test is a very poor substitute for verification. I'd be 
amazed if your tests would be extensive enough to pick that the program was 
different, whereas a comparison (masking or "reconciling" the date/time change) 
will give you 100% surety that the recompiled-program-with-no-changes is indeed 
identical, in all but the date/time, to the original.

If your audit procedures still insist that you do the regression-test, still do 
the comparison and ignore the results of the regression-test (it's wasted). 
Because you then have a task which is ignored/wasted, the tendency will be to 
become "sloppier" with the regression-tests in general.

Look at an site which accepts RC=4 as "OK" without needing to look at the 
diagnostics. It is highly likely that there's dark and stinky stuff in their 
systems. Slackness leads to slackness.

A program which is 100% identical (executable code) to the previous program has 
already been tested to the exact extent of the previous program. Are there 
auditors, in a financial environment, who buy that? Yes. Do they all? It seems 
not. Or it is open at least as to whether things have been explained to them.

ABO is different, the executable code changes. The changes are can be 
"reconciled", through the listing. An automatic verification is going to give 
way better results than any regression-test. Yes, for sure, that is a harder 
argument with an auditor, but even if the regression test is still forced, I'd 
go with the verification every time to "prove" the system, and, yes, that again 
means the regression-test (applied for the entire process) is again degraded.

Analogies are tricky, but how about this (abstracting all "human error"): you 
have a very long list of single-digits which you have to add up; you have a 
process which removes all sequences of digits which add up to a factor of 10 
(and is guaranteed not to have removed anything else) by a total of all of 
those digits at the bottom of the list, and lists all those removed numbers 
separately. We assume 100% accuracy either way (ABO isn't doing anything for 
that), and it is going to be quicker to add up the new "full" list than the 
original, and the total of the removed digits can be verified to the total in 
the new list to demonstrate that nothing is lost. Given that the original list 
has been audited for its addition, is there a requirement to again audit the 
speeded-up addition of the new list? 


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 with the message: INFO IBM-MAIN

Reply via email to