Re: I hate Activation Groups....

["John Taylor" <john.taylor@xxxxxxxxxxxxxxx>]

Buck,

I don't consider myself one of those half-dozen leading edge programmers,
but I do use a combination of named and *NEW AG's extensively.

In addition to the ODP sharing that you mentioned, AG's have important
consequences for commitment control boundaries, and static storage. The
implications for commitment control should be obvious enough, but not many
people seem to be aware of how static storage is handled in a named AG.

Briefly, when an ILE application is activated within a named AG, static
storage is initialized for all modules within the application, including the
linked service programs. Now, when you exit that application --even with a
hard leave such as RPG's LR-- the storage is not released back to the system
until the activation group is destroyed. Let's see what this means from a
practical standpoint, by using a typical example of an application that uses
a single AG:

- PgmMenu is a menu-driver that lives at the top of your call stack, and is
compiled with ACTGRP(QILE), or some other named AG.

- PgmAR and PgmAP are compiled with ACTGRP(*CALLER).

- SrvPgmAR and SrvPgmAP are also compiled with ACTGRP(*CALLER)

The user signs on to the system, and this activates PgmMenu. Then the user
follows this simple sequence:

- takes an option that calls PgmAR. This will activate PgmAR, SrvPgmAR, and
initialize static storage for each.

- user now exits PgmAR back to PgmMenu. Since the AG wasn't destroyed, the
static storage for PgmAR, and SrvPgmAR is not released back to the system.
Because it was a hard leave, the storage variables are simply marked for
re-initialization on a subsequent call.

- user now selects PgmAP, which activates both itself, and SrvPgmAP. The
user then exits back to PgmMenu, and we now have storage held for PgmAR,
PgmAP, and both associated service programs.

As you can see, with each new program that's activated, we're increasing the
amount of storage held by the job. It just keeps accumulating until the end
of the job. Of course, this has the potential to dramatically affect the
amount of main storage that your system requires.


John Taylor
Canada

----- Original Message -----
From: "Buck Calabro" <Buck.Calabro@commsoft.net>
To: <RPG400-L@midrange.com>
Sent: Wednesday, May 02, 2001 15:23
Subject: RE: I hate Activation Groups....


> >> If there was some mechanism to let the system know that the service
> >> program has been unloaded, then the system would re-load it again when
> >> the second call was made to the CL.
>
> >There is a mechanism - delete the activation group that contains the CL
> pgm.
>
> I wonder if there are more than a half dozen programmers on this list who
> use named AGs for production work.  By and large, the confusion at my
> workplace over named AGs stems from people trying to use a new gizmo
without
> cracking the manual first.
>
> Named AGs give us granular control over anything that can be scoped to the
> AG and not just the job.  The Big One is file opens with SHARE(*YES).  I
> seriously doubt that anybody is using a named AG to segregate static
> variables from other named AGs!
>
> Given the simplistic environment that _most_ AS/400 programmers are
> accustomed to (I'm excluding the half-dozen leading edge programmers), it
> seems that using a single named AG will suffice.
>
> Please, oh please correct me if I'm mistaken...
>
> Buck Calabro
> Commsoft; Albany, NY
> "Nothing is so firmly believed as
>  that which we least know" -- Michel Montaigne
> Visit the Midrange archives at http://www.midrange.com


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---