Re: RPGLE Trigger programs and Commit Control

<Craig>
1) If the database manager held back on the trigger processing until the
commit. Life would be simple. There would be nothing to undo. I'm using
commit control, that's a declaration that I don't want to declare the
transaction over until I commit. Why let processing bleed over into the
trigger's domain until I've confirmed the transaction with a commit?
</Craig>

... this wouldn't be too hard to implement:
- create a SRVPGM, providing exported procedures:
-- triggerFired, taking the complete Trigger Buffer, just putting the contents to a global variable to store it (if you would have multiple records in one transaction, dim would help.
-- commitIssued, taking the info of the commit exit program CCEXIT, and does all needed work of your trigger, if commit was issued and reinitializes the global buffer variable. In case of rollback, only initialisation is done.
-- at activation time (first call of one of the exported procedures) register the commit exit by call of the API.
- your trigger programm, only calls triggerFired, doing nothing
- create a commit exit programm (you'll find QRPGLESRC.CCEXIT and the needed headerfiles on sourceforge too, as an example). If CCEXIT is called, simply call commitIssued of your SRVPGM.
Let it all run in *caller.

that's it!

D*B