Re: How to test a service program

David

This is a common situation - commitment control might help here, but one idea is to read the record (not for update, or use the (N) extender to release the lock), wherever you are, and put the values into some holding tank. Then, just before you update it, read it again for update with the lock - compare the values to what you got the first time - if changed, well, do whatever you have to. Maybe send a message, maybe something else.

This is an ancient technique!!

Regards
Vern

David FOXWELL wrote:

-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Charles Wilt
procedures. Also by definition, it's up to the programmer to
not only ensure that any global variables are used correctly,
but to define "correctly" in the first place!

Charles,

What about this kind of scenario :

Procedure P1 in a test program reads File1 and updates a record R1.

Later, another programmer writes P2 that also affects the same record, although that might be a completely unrelated task to that of P1.

The result of the test on procedure P1 might be lost, or worse, it may be assumed to be correct when it is actually the procedure P2 which is inducing the expected result.