Peter - Well said.


On Thu, Oct 13, 2016 at 1:01 PM, Farley, Peter x23353 <> wrote:

> Bill,
> 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.
> Peter
> -----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
> Peter,
> 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

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to with the message: INFO IBM-MAIN

Reply via email to