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



... just to clearify: supposing the trigger mediator runs in a named ACTGRP and there would be a way to get the information in which Activation group the programm, firing the trigger runs, then you could prpaghate commit/rollback to the SRVPGM (similar situation in ArdGate, here I get the information from DB2)

Dieter

--------------------------------------------------
From: "Vern Hamberg" <vhamberg@xxxxxxxxxxx>
Sent: Friday, October 08, 2010 6:31 PM
To: "RPG programming on the IBM i / System i" <rpg400-l@xxxxxxxxxxxx>
Subject: Re: avoid running ILE programs in the DAG...

Yeah, but not what I was asking - you asked for a way to know from
which activation group the trigger was fired. *CALLER takes care of
that. If fired from the DAG, that's the AG. If fired from a named AG,
that's the AG you're in.

A trigger mediator such as Alan's that then sends requests to a
never-ending-program - yeah, that'd be a problem, since there is no
coupling of the firing AG and the NEP. I guess that's what has been
discussed here already.

Vern

On 10/8/2010 9:19 AM, dieter.bender@xxxxxxxxxxxx wrote:
... the OP didn't want to run his trigger mediator and the subsequent
SRVPGMs in the default Actgrp and was looking for possibilities to avoid
this.

D*B

--------------------------------------------------
From: "Vern Hamberg"<vhamberg@xxxxxxxxxxx>
Sent: Friday, October 08, 2010 2:25 PM
To: "RPG programming on the IBM i / System i"<rpg400-l@xxxxxxxxxxxx>
Subject: Re: avoid running ILE programs in the DAG...

Dieter

Isn't that already what the system does with *CALLER? I have not thought
of that in precisely this way, but that seems right.

Vern

On 10/8/2010 2:57 AM, dieter.bender@xxxxxxxxxxxx wrote:
... 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.


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