× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



... if there would be a chance to know from which activation group the trigger was fired, the problems are looking solvable to me, otherwise: no chance to bring commit to work correctly.

D*B

--------------------------------------------------
From: "Alan Campin" <alan0307d@xxxxxxxxx>
Sent: Thursday, October 07, 2010 9:58 PM
To: "RPG programming on the IBM i / System i" <rpg400-l@xxxxxxxxxxxx>
Subject: Re: avoid running ILE programs in the DAG...

Everything is now running in *CALLER (for some time) which results in all
service programs running in DAG because of triggers running there which I
would not prefer but don't seem to have any choice.

On Thu, Oct 7, 2010 at 1:43 PM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

On Thu, Oct 7, 2010 at 8:41 AM, Larry Ducie <larry_ducie@xxxxxxxxxxx>
wrote:
> Maybe the problem you describe is a side effect of the DB being
sandwiched between your calling code and your trigger. I'd imagine IBM had
to do some serious smoke/mirrors stuff there to try and take the DB out of
the equation when using a trigger with *CALLER. I'd imagine the DB runs in
the DAG so there'd be two control boundaries in there but I'm sure a trigger
running in *CALLER still takes the AG from the object that called the DB
code. This suggests there's some serious fudging going on in there to make
that happen!. Maybe they haven't got it quite right yet. It maybe be that
particular circumstance where your issues arise and not in the general ILE
environment itself.

I'm with you Larry, I think IBM is doing something special behind the
scenes for trigger programs.

I pointed out over a year ago to Allen that his trigger (mediator)
program was using a named activation group instead of the *CALLER
that IBM recommends and that his example service programs also were
created with a named group instead of the recommend *CALLER.

That may have been why he didn't see commitment control working,
*CALLER is basically a requirement for that.

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


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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.