Re: RPGLE Trigger programs and Commit Control -- RPG400-L

The way a trigger program is supposed to work...

The trigger program should use both the USROPN and COMMIT(myIndVar)
keywords on the f-spec. Along with ACTGRP(*CALLER) h-spec.

That way it can check the commit flag in the buffer before opening any
files the trigger will update.

Then either open the files with commitment control, or without.

Now if the trigger is fired by a process using commitment control, the
updates made by the trigger will also be rolled back.

Charles

On Wed, Jun 6, 2018 at 9:58 AM Craig Richards <craig@xxxxxxxxxxxxxxxx>
wrote:

Hi All,

I'm just trying to consider the implications of having an RPGLE trigger
program on a file which is being updated by many programs, some of which
use commit control and some of which do not.

At the moment the trigger program runs in the caller's activation group and
is not using commit control itself.

The first thing I noticed is that the trigger program gets called when the
UPDATE is performed, not the COMMIT, I guess I can understand why this
might be in terms of database integrity but it makes life tricky because if
the application decides to do ROLLBK, the trigger has already done it's
stuff and in my case is initiating asynchronous processing which could only
be undone by building a set of reversal transactions.

Which brings me to my second point.

If the Application performs a ROLLBK rather than a COMMIT, I thought that
the subsequent change to the database would fire the trigger program again.
Allowing me the possibility to build a reversing transaction. My testing so
far indicates that the trigger program only gets called after the initial
UPDATE and not as a result of the ROLLBK. This does not make sense to me.

I understand that I could build commit control into the trigger program but
in that case the normal design would be to have it in the same commit block
and controlled by the program doing the file update.
I don't see how this can work well because the trigger programs gets called
by the UPDATE, at which point it goes ahead and does it's processing. If a
rollback ensues, it's too late, the trigger program has already initiated
the asynchronous processing. Yet the trigger program cannot hold back it's
processing until the COMMIT because as far as I can see it only gets
invoked by the UPDATE.

Has anyone else wrestled with triggers and commitment control?

Does anyone disagree with my assertion that:
1) The trigger program gets called when the UPDATE is issued not when the
COMMIT is issued.
2) The trigger program does not get called if the record is reverted to
it's original state via a ROLLBK.

thanks and regards,
Craig
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD