Recompiling a program with no changes. Do you "regression test"? No.

You compare the object (masking the date/time). If it is the same (as in 
identical) - what would a regeression-test show?

OK, compiler may have been patched. Doesn't matter. The executable code 
generated is the same.

Run-time (LE) may have been patched. OK, but regression-test that, not every 
single program.

What if the executable code turns out to be different? Why test that? You need 
to find out what is different, not test it, you're not expecting differences, 
so explain tht first.

If after analysis it is proven that the executable code should be different, of 
course, test it, because it is no longer a "no change" compile.

Yes, there's rules. The rulers should be aware of the "psychological" impacts 
of rules applied in... the wrong... circumstances. If you "blanket regression 
test" you for sure are not verifying that the executable code is identical. 
Tick "Yes" for Regression-Tested, tick "No" for "All changes tested" because 
you don't know of a change. Testing something with no changes leads to a 
climate of "you don't need to bther much with that one".

ABO is a little different, in that the executable obviously changes.

What should not happen is any change in the logic (optimisations for that are 
out-of-bounds for ABO).

ABO produces a listing. Manually/automatically inspecting the listing produced 
should provide a very high level of confidence in "no logic changes".

Yes, if you're going to regression-test ABO'd programs it greatly affects the 
cost/benefit analysis.

I'd be happier without the "PERFORM A THRU B where B precedes A" problem. 
Automatic verification of "no logic change" should help. Even if that is no use 
to the argument "don't regression-test", still consider doing it, it is looking 
for something concrete, whereas the regression-test is... a regression-test 

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

Reply via email to