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.



John Taylor



+---
| 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
+---