|
midrange.com
Would this also mean once the CGI request job has created the activation
group that it stays in memory until CGI request job has ended?
Thanks
Jason Bender
EDPS (Electronic Data Processing Services)
jbender@xxxxxxxxxxxx
804/353-1900 Extension 2887
"Holden Tommy"
<Tommy.Holden@hcaheal To: "RPG programming
on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
thcare.com> cc:
Sent by: Subject: RE: Connection
Pooling - Activation Groups
rpg400-l-bounces@midr
ange.com
09/06/2006 09:29 AM
Please respond to RPG
programming on the
AS400 / iSeries
Well...kinda...an activation group will exist in each job. If the
activation group hasn't been created for the CGI request job then it
will have to be created.
Thanks,
Tommy Holden
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
jbender@xxxxxxxxxxxxxxxxx
Sent: Wednesday, September 06, 2006 7:27 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: Connection Pooling - Activation Groups
Scott/Bob,
Thanks for making this more clear for me to understand.
(So the below statement would be true)
In my situation working with the Web users, once this activation group
has
been loaded into memory, any connections from the web calling this
program
will have this activation group available to them. This activation group
is
available until its deleted out of memory (reclaimed).
Thanks
Jason Bender
EDPS (Electronic Data Processing Services)
jbender@xxxxxxxxxxxx
804/353-1900 Extension 2887
"Bob Cozzi"
<cozzi@xxxxxxxxx> To: "'RPG
programming on the AS400 / iSeries'" <rpg400-l@xxxxxxxxxxxx>
Sent by: cc:
rpg400-l-bounces@m Subject: RE: Connection
Pooling - Activation Groups
idrange.com
09/05/2006 05:03
PM
Please respond to
RPG programming on
the AS400 /
iSeries
Scott,
Just to be more clear, the program doesn't run faster, it loads and
starts
running in a shorter timeframe than it did previously because no
activation
group is being created.
Just didn't want Jason to think the program runs faster the second time.
It
runs
the same, although the start-to-end delta gives one the impression that
the
program ran faster, it was just the removal of the steps in the path
that
allow
it to start up quicker.
-Bob Cozzi
www.iSeriesTV.com
Ask your Manager to watch iSeriesTV.com
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On
Behalf Of Scott Klement
Sent: Tuesday, September 05, 2006 3:58 PM
To: jbender@xxxxxxxxxxxxxxxxx; rpg400-l@xxxxxxxxxxxx
Subject: Re: Connection Pooling - Activation Groups
Hi Jason,
I'm sending a copy of my reply back to the RPG400-L mailing list, since
it's where this thread started, and I feel it's important for follow-ups
to go there as well. That way, everyone has a chance to learn, and
everyone has a chance to make comments.
In keeping your activation group open, lets say the program is called again, what happens with the activation group? Does it get closed or
will
it try to reclaim the activation group?
ILE programs are loaded into memory (the technical term for that is called "activation") into an activation group. The program then remains in memory until the activation group is reclaimed (i.e. deleted from memory.) Let's say you compile your program with ACTGRP(JASON). The first time this program (or any other program with the same activation group name) is called, the activation group gets created in memory. Your program is then loaded from disk into memory into this activation group. It's then run. On subsequent calls (assuming you haven't reclaimed the activation group) the program is already loaded into memory, and therefore runs very fast because it doesn't have to be re-loaded into memory. If you're writing an RPG program, and the program ended with *INLR off, the files can be left open from call to call, which speeds things up even further since the files don't have to be closed and re-opened on every call. -- This is the RPG programming on the AS400 / iSeries (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 AS400 / iSeries (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 AS400 / iSeries (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 AS400 / iSeries (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 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.
