Peter - Well said. Sam
On Thu, Oct 13, 2016 at 1:01 PM, Farley, Peter x23353 < peter.far...@broadridge.com> 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 > To: IBM-MAIN@LISTSERV.UA.EDU > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
