Activation Group-RpgIle

[rtenali]

hi all,
Can you give more information about activation group, when activation group can be used?, what is advantage of activation group? please give me clear cut and with examples....

[mksamy_99]

Re: Activation Group-RpgIle

hi tenali,
please go through the entire article.


How do I use activation groups?
This answer is intended to be a starting point for ILE beginners.
More than most FAQ answers, it is NOT intended to be the absolute,
correct and only way to approach activation groups.

This FAQ is a work in progress, based mostly on the RPG400-L archive
thread at http://archive.midrange.com/rpg400-l...ads.html#00130

Everyone reading this should have already read the ILE Concepts
manual (V5R2):

http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c4156066.pdf

and the RPG IV Redbook:

http://www.redbooks.ibm.com/abstracts/sg245402.html

The activation group concept is intended to be a way to subdivide a
job into smaller portions, especially in the areas of overrides and
static memory. An activation group does NOT span jobs! The corollary
is that programs which run in the same AG are intended to be developed
as a single cooperative application.

Activation group strategies revolve around the various parameters
on the CRTRPGMOD, CRTBNDRPG, CRTPGM and CRTSRVPGM commands:
NAG - Named activation group. Includes
*NEW - create a system-named group when the program is activated
*CALLER - inherit the AG from the program that called this one
DAG - Default activation group. Usually OPM, but can include
*CALLER - inherit the AG from the program that called this one

Remembering always that an AG is a subdivision of a job, why would
we want to do such a thing? To answer that, we need to think about
application design for a bit. In most OPM designs, a typical job might
consist of a single CL program driver that calls several other CL
programs. They, in turn might issue an override and call an RPG program,
like this:

CLMAIN
CL01
OVRPRTF FORMTYPE()
RPG01 /* Print selected records */
RPG02 /* Mark records for deletion */
CL02
OVRPRTF FORMTYPE()
RPG03 /* Print totals */
RPG04 /* Clear totals for next month */

Let's modify RPG03 so that it uses a subprocedure. Because of that
subprocedure, we can no longer use DFTACTGRP(*YES) [As Jon Paris often
comments, we should really think of this parameter as OPMCOMPATIBILITYMODE.]

What do we do?
If we use *NEW, then RPG03 will create a new AG, run there and then the
system will delete the AG when RPG03 completes. That's a fair amount of
overhead considering that we don't _need_ the job subdivided.
If give the activation group a custom name like BUCK, then we have two
problems:
1) We have to know when to destroy AG(BUCK), because the system won't clean
it up for us.
2) We need to worry about name collisions. What other programs in this job
might use AG(BUCK) and accidentally share overrides? What other programs
NEED to share overrides? Do they have the same AG name?

So while choosing a single named AG like your company name might seem like
a good idea at first, you should think about using *CALLER. *CALLER allows
you to compile and use subprocedures, but you don't have to worry about
whay activation group to run in. Everything runs in the default AG, just
as it always did! Programs running in the same AG are a designed to share
resources. This strategy implies that you will never try to end the activation
group (for instance with RCLACTGRP) and that you will never need to re-activate
a program.


Service programs.
Service programs are like "procedure libraries." They provide the ability to
semi-dynamically load code at runtime. "Semi" because once a service program
is activated, it stays activated until the AG or job ends.

The implication is that you can't re-compile a program/service program that
runs in the DAG unless you get everybody out of it. That is, they won't
see the change until their job (and DAG) ends.

Once you've set up a few service programs, you'll eventually run into the
scenario where you want the service program to be shared between G/L and A/R,
but you want different overrides (or static memory) for each app. Now, you
want to subdivide your job into different activation groups. You're an ILE
programmer!


Enter *NEW/*CALLER.
By compiling the first A/R program as AG(*NEW), a new AG will be created every
time ARMENU runs in the job. All the subsequent programs will inherit that
AG. YOUR overhead is reduced because you don't need to keep track of who is
using what private AG name, and the system will clean up the AG once all the
programs are done with it.

MAINMENU DAG
ARMENU *NEW 5F4A716B (system generated)
ARINQ *CALLER 5F4A716B (inherited)
CUSTSRVPGM *CALLER 5F4A716B (inherited)
GLMENU *NEW 2A9F7E14 (system generated)
GLINQ *CALLER 2A9F7E14 (inherited)
CUSTSRVPGM 2A9F7E14 (inherited)

You can see that the system created TWO separate AGs and thatthe service program
CUSTSRVPGM keeps the A/R and G/L apps separated from each other. So, you can
keep a counter rolling of the number of accounts viewed today, and the counter
for A/R will be different from the one for G/L.

This is impossible to do in OPM.

This *NEW/*CALLER strategy is the consensus of the group at RPG400-L


Confused? read again and go through the links provided in this article.

Thanks
Muthukumara Samy

[giri]

Re: Activation Group-RpgIle

Pls go thro the following links for more info ...

http://www.itjungle.com/fhg/fhg021104-story01.html

http://faq.midrange.com/data/cache/252.html