× 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 we talk about (embedded) SQL! Using Activation Group *NEW might not be a
good idea.
When executing an SQL statement (in a program or procedure) a FULL OPEN
(full optimization) must be performed, i.e. SQL statement must be analyzed
and gets perhaps rewritten, access plan must be validated or rebuild based
on the existing access paths (indexes and logical files) and based on the
answers of the statistics manager about the data composition. This step is
very fast, but the next step within the optimization, opening the data path,
i.e. building all the (temporary) objects described within the access plan,
joining them together and populating them with data is very time consuming.
That's why SQL tries to keep the ODP (Open Data Paths) open as long as
possible, so for the sub-sequent runs only the data within the ODP must be
refreshed (PSEUDO OPEN) which is much faster than a full open.
When compiling a program with embedded SQL the CLOSQLCSR (Close SQL Cursor)
option is set per default to *ACTGRP, i.e. an ODP can stay opened as long as
the activation group is active.
... but when creating a program with the new activation group, everything
which runs within the activation group is removed at the end of the program,
i.e. also the ODPs are removed.
When rerunning the program, FULL OPENs for each SQL statement within the
program must be performed again.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser


"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
?Train people well enough so they can leave, treat them well enough so they
don't want to.? (Richard Branson)


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Nadir
Amra
Sent: Montag, 17. Februar 2020 23:24
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Activation Groups, yesterday and now?

When a job ends, all resources tied to job will be reclaimed.

There are some resources tied to activation group like memory, and there are
some resources tied to job, like socket descriptors.

If you have programs calling other programs within the job and there is lots
of pre-initialization that is done (e.g. building tables or objects within
memory) that may be used independent of who calls your program within the
job, and you do not want to incur the performance penalty of always
initializing on each call, then you would want to use activation groups.

I also know Db2 processing has some things tied to activation groups such
as commitment control, but I am not an expert in this area.



"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> wrote on 02/17/2020
04:09:23 PM:

From: Patrik Schindler <poc@xxxxxxxxxx>
To: Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxxxxxxxx>
Date: 02/17/2020 04:09 PM
Subject: [EXTERNAL] Activation Groups, yesterday and now?
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxxxxxxxx>

Hello folks,

as far as I understand, activation groups are kind of a shared
memory area for multiple programs to be run in. Correct?

Years ago, I stumbled across a file pointer not jumping back to
*LOVAL, because the default compile option of ILE RPG (at least with
V4) was DFTACTGRP(*YES). Obviously, certain attributes of programs
will be retained between runs. That's when I started to always use
DFTACTGRP(*NO) ACTGRP(*NEW) when compiling.

I'm very used to the concept in "common" operating systems that if
you end a program, used resources are claimed back by the OS and
said compiler options force this behaviour.

Now I wonder, what are activation groups actually good for? Or, have
been good for 30 years ago? What's the benefit in putting a bunch of
programs into the same (named, or default) activation group today?
Is it "just" for omitting the overhead for repeated program
activation between runs? Even on my ancient 150, programs are
starting blazingly fast.

I have a dim idea what "activation" does. AFAIK it's tied to the SLS
peculiarities. An unactivated program is just an ordinary object at
some address in the vast memory space. An activated program has
associated certain resources, so it is actually able to run and do
stuff. (At least that's what I understand from reading https://
www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/ilec/ileacpa.htm)
Correct?

I've been reading through some resources at the internet but there
was none which gave clear answers to my above questionary. Most of
them also are a bit dated.






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.