I'm not saying just instal the ABO and get on with it. I'm talking about 
per-program, beyond an initial "proving" stage (of the procedures for working, 
implementation, gauging actual improvement with actual programs, including even 
detailed work on "beast" programs). I'd also expect "parallel" running, of 
appropriate lengths of time, and appropriate includes "decreasing" as 
"confidence" is built.

I'd not even be averse to a "bust it if you can" period. Not only toss bad 
programs into it, but deliberately try to create things to not work. Yes, 
there's been one issue, so that increases the chance of there being another. 
The V5+ experience is that many people commonly use COBOL in ways that were 
"unexpected". For all of those with V5+, there is not evidence that any of 
those things, not a single one, caused a problem with ABO (V5+ has no 
(reported) problem with that stupid PERFORM construct).

Now, to argue against myself. I always recommend that beyond program-testing, 
all compile options should be the same as they are to be in Production. You 
can't just slap on OPT at the final point. Not because OPT doesn't work, but 
because the code "moves". Since the code moves, something which was previously 
stamping innocuously on program code *may* now stamp on something more 
inconvenient. That's not ABO's fault, but could be a side-effect, it is the 
fault of a bad program. Is regression-testing genuinely likely to uncover what 
tends to cause such things (and they are not at all common) over a "random" 
parallel run?

ABO *may* expose a bad program, not because of ABO itself, but because of the 
bad program. If you have a program which "intermittently fails and we've never 
discovered why" or the program that eveyone hates to touch, then yes, it is 
reasonabe to take different measures - and perhaps on balance not even ABO 
things like that without remedial action first.

For me, in this type of case, I am concerned that a regression-test (expensive) 
may be a placebo, and at worst lead to a false sense of security. Bad code is 
bad code. Passing a regression test does not change that. With a correct 
program I have no fear for ABO'ing. My belt-and-braces would be an (automatic) 
analysis of the ABO output, consuming considerably fewer resources.

As a side note, to a separate post, ABO doesn't come out of Markham, but from 
IBM Research, although obviously not in a vacuum.

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