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


  1.  Home
  2. RPG400-L
  3. October 2010

Re: avoid running ILE programs in the DAG...

... I don't have any requirement, for my needs it does, what I need. All, RPG is not able do, could be done in Java, better and with much more programmer performance - thats the reason behind the fact, that there are tons of Open Source in Java ande very few written in RPG. Its true, an activation group is related to its Job, running in. Activation Groups with the same name, don't share anything running in diffrent jobs.

Dieter

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

Yeah, I can see benefit in that. Maybe one issue is that AGs are
within their own jobs - is it true that, even if you have AGs with the
same name in different jobs, that they are not related?

Maybe this is something to offer as a DCR or requirement to IBM, once
you and whoever else can put together a good description of the problem
and what its benefit is, to change it. I've mentioned logging in to
www.common.org - I believe there is also a COMMON Europe Advisory
Council, but I don't know if they collect requirements as we do here. If
not, you could do it on the USA COMMON site.

Regards
Vern

On 10/8/2010 12:13 PM, dieter.bender@xxxxxxxxxxxx wrote:
... 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.


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