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:[email protected]] On Behalf Of Bill Woodger Sent: Thursday, October 13, 2016 2:31 PM To: [email protected] 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 [email protected] with the message: INFO IBM-MAIN
