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?
DSPLAY "A MESSAGE"
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN