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



Mike,

It doesn't matter how the jobs are started, activation groups act the
same way. The number of jobs started up depends upon the upper limit on
connections you've defined in the pool. There is a one to one
relationship between connections and QZDASOINIT jobs. How many end up
being started is a function of your pool settings, how the code is
written (it's possible for a single servlet to have multiple active
connections to the database -- this is bad, BTW), and traffic volume.

Matt

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike Eovino
Sent: Wednesday, September 06, 2006 11:38 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: Connection Pooling - Activation Groups

Just to confuse the matter a little further (I work with Jason and
know some of the details of this)...

We're not using CGI.  The stored procedure is being called by a Java
servlet running from inside WebSphere Application Server, which is
hosted on another iSeries system.  So the stored procedure should be
running in one of the QZDASOINIT jobs on the target system.

We are using connection pooling for database requests from WAS, so the
QZDASOINIT job should be reused to some extent.  We're pretty new to
WAS, so we're not really sure how connection pooling and QZDASOINIT
work together, or how long the QZDASOINIT jobs last.    Do they last
forever like DRDA requests that are handled by QRWTSRVR jobs?

I would think that the handling of the named A/G would be pretty
similar, however.  So that once the first call sets up the A/G in the
QZDASOINIT job, subsequent calls that are serviced by that same
QZDASOINIT job would reuse the A/G.

And if we were to have a large enough volume of requests from WAS to
our target system, could we conceivably have several QZDASOINIT jobs,
each of which could have that named  A/G?

Sorry if I'm moving into an area that would be better handled by the
midrange or Java list.

Mike E.


On 9/6/06, Bob Cozzi <cozzi@xxxxxxxxx> wrote:
Jason,
If my answer didn't answer this question for you, then let me rephrase
it.
The term "CGI Request job" is probably not what you mean.
I think you mean "CGI Request". A CGI job typically doesn't end until
the server
is ended or an error occurs in a program running in that job.

The Named Activation Group ("A/G") is created on the first call to the
CGI
program.
When the CGI program returns, the A/G remains in memory.
If another CGI request comes in (from the original client or another
one) and
that same CGI job is called upon to process this new request, then A/G
and
therefore the program is already in memory, and starts running.
The named A/G stays in memory until a program blows up in the job or
the job is
ended or the server instance is end.

-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 jbender@xxxxxxxxxxxxxxxxx
Sent: Wednesday, September 06, 2006 8:38 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: Connection Pooling - Activation Groups


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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.