Re: RPGLE Trigger programs and Commit Control

[Charles Wilt <charles.wilt@xxxxxxxxx>]

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