When starting commitment control what is the CMTSCOPE? Default = *ACTGRP?
If so try to set the Commitment Scope to *JOB.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
?Train people well enough so they can leave, treat them well enough so they
don't want to.? (Richard Branson)
-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxx> On Behalf Of Craig Richards
Sent: Donnerstag, 7. Juni 2018 10:26
To: RPG programming on the IBM i (AS/400 and iSeries)
<rpg400-l@xxxxxxxxxxxx>
Subject: 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
--
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
midrange.com
