I just took a case with a guy who was using READU and WRITEU to lock and retain a lock on a file. The reads and writes would work for a while, then after a week or so, a group lock would be set that prevented the WRITEU. No apparent reason. Then he remembered that he had a CALLX on the file. Turned out there was a bug in the trigger that was creating an item ID for an audit file. Circumstances sometimes led to the ID being more than 100 bytes long causing the CALLX to fail and strand the group lock. He found and fixed the issue.
Thing is, he's lucky that the trigger was failing in a way that caused a lock contention that triggered ( pun intended ) an investigation. If the trigger had failed in some other way that allowed the main process to continue without error, the update to the file would also have failed without overt warning. Yes, there would most likely be something in the ERRORS or RUNTIME-ERRORS files, but nothing that would have sent the process into the debugger or anything else that would have let the user know that something was wrong ( see the sample at the end of the post ).
So, KEEP AN EYE ON YOUR CALLX TRIGGERS!! Do LIST-ERRORS and LIST-RUNTIME-ERRORS on a regular basis, keep your triggers as simple as possible, and make sure you test them in a development environment before launching them live!
products
008 callx sqldemo,bp, testtrig
testtrig
001 subroutine testtrig(i)
002 stop
003 return
:ed products 7
top
001 Ninja Calc
.r
001 New Description
.fi
[221] '7' filed.
:ct products 7
7
001 Ninja Calc
------------------------------
Brian S. Cram
Principal Technical Support Engineer
Rocket Software
------------------------------