In my opinion, you have mixed two tools that realy are not linked.
first is triggers. triggers are on proccess side : for example if you had no triggers, you would have called the progs yourself. A trigger is a program you call, but not directly, you are just the trigger event, is is enough.
I think trigger is outside of the problem
second are commitments. Commit are on data side : it is the tool that permit the global consistency of the information.
I am very surprised by “commitment control status of *NONE” used inside a committed flow of update. I thought is is not possible.
I assume you have checked add files are journaled
Work on having the same commitment level from the beginning to the end of the transaction data flow.
Send a feed-back of your tests, successfull and not successfull. There is still so much 400 site that don’t use journaling, you will have many readers (me included)
It’s perfectly possible to have “commit *NONE” processes inside a commitment boundary. Obviously the files being updated by the triggers are not journaled and therefore probably <i>can’t</i> cooperate with commitment control. Get the trigger developers to fix them.
Simply put, the database is incorrectly implemented. If you want any kind of consistent rollback, the database configuration will have to change. The files will all need to be journaled and the triggers will have to inherit the commitment definition.