There are a number of different items within this topic.

"Just a recompile", where the object is expected to be identical, 

To my mind, no. It should be verified as identical. If it is not, the reason 
should be identified and what follows depends on what is found out.

I would not expect regression-test cases to necessarily notice that the object 
is different if subtly so.

"Slap on OPT at the last moment before going to Production". I'd never suggest 
this, so for me it is a hypothetical question which does, however, shed some 
light on the "to what extent an ABO'd program should be tested".

For me, changing any compile option at the moment of going to Production 
invalidates all the testing up to that point. So if you're going to Production, 
as in at that time, then no, I don't see what you could do to test it. It's 
like a contradiction in terms, but if you are really going to Production and 
really changing an option which affects the generated code, then I don't see 
how you can test it (effectively you go the "Production Fix" route).

"ABO changes, can they be verified": there is IBM advice on testing of ABO.For 
now, until I can transcribe (or find it written) I'll paraphrase it as "become 
confident with the product with your early testing, then test for performance". 
The "test for performance" suggestion is interesting. Is there an implication 
that sometimes things regress in performance? Oh no, another subject added to 
the already complex mix.

Enterprise COBOL and OPT. Does OPT change the results produced by a program? 
Well, given data which conforms to PICture and COBOL which conforms to the 
Language Reference, and impact of options as described in the Programming 
Guide, and, perhaps, things in the Migration Guide, No. OPT does not change how 
such a program works. If it happens to do so, then it is time to "reach out" to 

As an example, if you write a program which only uses literals or "constants", 
OPT (at least up to 4.2) will (I don't know if there is a limit as to the size 
of the program) just work out the result and not bother with executing the 
code. I suspect V5+ does this, even more so.

Might there be difference in output with non-conforming data or a 
non-conforming program, per level of OPT? For sure. Since there is no "defined" 
behaviour for those cases, it would be... difficult... for OPT to be able to 
second-guess what was considered to be the correct result.

"Can all programs which could ever exist in this or any potential Universe be 
verified automatically". No. But, so what?


Can that program (with minimal necessary stuff at the beginning) be verified? 
Yes. (I hate to think of the disavowals of that, so hopefully in a separate 
topic, this one is twisted enough already).

Can something more complex, expressed in a language more suitable to automatic 
verification, be automatically verified, as it is transformed, as being 
equivalent to its starting-point? The claim seems to, from ABO, yes. It is 
their claim, not mine, it is what does underly the quote (from the User Guide 
for ABO, although it may also appear in marketing material).

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

Reply via email to