Activation Groups and Modular Programming

Hi John and Martin

>Date: Fri, 20 Jul 2001 09:26:24 -0600
>From: "John Taylor" <jtaylor@rpg2java.com>
>Subject: Re: re. Access Groups and Threads
>
>Hi Martin,

>>I'm beginning to get the impression that we're the only company in the
>>iSeries world using named AGs as they were designed to be used (as I
>>understand them).  Since I was the driving force behind our use of them,
>>that gives me a warm glow :-)  -- though at the same time, the same
>>sense of disappointment I get when I realise there are people who don't
>>use journalling and commitment control.


<snip>

>>When we considered activation groups we realised that there were a
>>number of utility-type functions that users would need to access from
>>many different menu options (access to common files, like the customer
>>master, is a good example).  So we put the procedures that do those kind
>>of functions into service programs, which run in their own, named AGs.
>>These AGs are never reclaimed, so stay active until the user signs off.
>>Entry-point programs also  run each in their own named AG, but these are
>>reclaimed when the user exits back to the menu.


>There is no *one* right way to use AG's.

>What you're doing here is an effective strategy, and closely resembles what
>I do myself. The main exceptions are that I've started using *new instead of
>named on entry-point interactive programs - those called from a menu. And I
>don't run all of my service programs in a separate AG.

>For service programs, I have some that live in a named AG --utilities such
>as yours-- and others that run in *caller. There are three primary factors
>that I use to decide which goes where:
>1) commitment control boundaries
>
>Almost always, when the service program involves data updates, it goes to
>*caller so that it's within the same commitment control boundary. The
>exception is described further down.
>2) data caching
>
>Many of my service programs cache data internally. The type of data I'm
>caching will dictate what AG I'm going to run it in. For example, a SrvPgm
>that returns Company Tailoring information runs in a common named AG,
>because on our system, a user can only be in one active company at a time,
>so 99% of calls to this service program are going to involve the same
>Company tailoring record. (All companies are included in the same DB, and
>distinguished by a unique company ID)
>
>On the other hand, a SrvPgm that returns g/l account information is going to
>run in *caller, because there is a greater likelyhood that a single user job
>is going to have multiple active programs -  each of which will be accessing
>a different g/l account record.
>3) frequency of use
>
>Using the same Company Tailoring example, if the service program does
>updates (ie: changing configuration options), yet doesn't run under
>commitment control --which I don't normally employ for single record
>updates-- then the deciding factor falls upon frequency of use. A service
>program such as Company Tailoring, is fairly large, and used very
>infrequently, so it goes to *caller, because I don't want it sitting in a
>common AG, holding memory for the duration of the job.

I have come to a tentative conclusion that AGs are a way to isolate or
rather insulate a program from other programs within a job.
One can then invoke a function and be reasonably sure that it will
not affect or be affected by other programs within the job.
A parrallel concept is local variables, where one can name a
variable what one will and be sure that it will not affect other
variables nor be affected by other variables provided that is local.
In short AGs facilitate modular programming.
John and Martin am I close to the mark or wildely off.

>John Taylor

TIA
Frank Kolmann





__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience 
the convenience of buying online with Shop@Netscape! 
http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at 
http://webmail.netscape.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
+---