Re: RPGLE Trigger programs and Commit Control

Hi Dieter (I hope this is the correct name - it seems better than calling
you D*B )

Thanks again for taking time to post. I do appreciate it.

I will consider your words, if nothing more than for my own education as I
haven't looked at commit exit program.
However I will most likely take my previously suggested approach and
exclude certain programs from the trigger processing, putting that code in
the application programs.

Here are my reasons for this:

1) I prefer to keep trigger programs as light as possibly. This is because
they have to perform as part of the database update and therefore be
efficient, and the other reason is that, to me at least, it's kind of
"under the covers" processing. So any heavy transactions or business rules
I tend to port into something like an asynchronous server where the code is
more visible and it's not holding up critical I/O. This is just my opinion
and preference, I don't expect everyone to agree.

2) When there is a possibility that the database can be updated via
DDRA/DDM (QRWTSRVR Jobs) or Database Host Server (QZDASOINIT Jobs) which
hang around for a while and get re-used via different connections, you
cannot leave the trigger program resident or you are just asking for
trouble. Therefore every database access would need to start up the trigger
program each time, then the trigger program would have to find and
dynamically bind in the service program each time, then this is registering
the exit program each time. I'm sure many, maybe most people would argue
that this is all find and dandy and just a walk in the park for an IBMi,
but I'd personally just rather not have all of that going on in my triggers
plus the overhead and logic of storing up all of the data ready for when a
COMMIT is issued. I can see how this approach could work though.

But I'm grateful you took the time to send me your thoughts and some
information I didn't know about before.

best regards,
Craig

On 7 June 2018 at 08:55, D*B <dieter.bender@xxxxxxxxxxxx> wrote:

<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
--
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