Re: Activation Groups for Beginners

[EThompson@xxxxxxxx]

OK I am just curious to why an activation group would be used?  I have
heard of them but never had any reason to use them.  I asked other
programmers here and they have never used them either...or used the default
if that is the case.   I am just unsure if there are benefits to them?
What additional functionality/control do they give you? etc.

This only stems from curiosity from Buck's message...

Elonna Thompson
CHCS Services, Inc.
Information Technologies
850-432-1700  x2204

Message: 3
From: Buck Calabro <Buck.Calabro@commsoft.net>
To: rpg400-l@midrange.com
Subject: Activation groups for beginners
Date: Mon, 4 Mar 2002 18:11:50 -0500
Reply-To: rpg400-l@midrange.com

I started writing this giant note about activation groups, but then
realised
that having an ongoing peer review would be better.  So here's my opinion
on
AGs.

Multiple AGs are intended for complex environments.  A programmer moving
gradually from S/38 code into ILE doesn't need to be uptight about what AG
to run in.  Run in QILE.  NOTE: This is a controversial opinion.  I'll try
to substantiate it below.

NAG - Named activation group
DAG - Default activation group
Scope - How long a variable/program activation/OVRxxx lives

NAGs are not system objects.  They are like QTEMP - there's one for each
job.  I keep it straight by thinking of a NAG as a subdivision of a job, so
my QILE runs in my job: 123456/BUCK/QPADEV0001/QILE and your QILE runs in
your job: 1234567/QPGMR/QPADEV0002/QILE.  They do not know about each
other,
any more than job QPADEV0001 knows about QPADEV0002.

Named AG's come in to play for two things: Shared file opens (override
scoping) and program activations.

Override scoping.  An override issued in the DAG carries forward into all
other AGs.  An override issued in a NAG exists only in that NAG for that
job.  This behaviour is fine for the situation where an OPN CL program does
some overrides, then calls a mix of ILE and OPM programs, where the ILE
programs run in a NAG.  If you use shared ODPs, post a to this thread to
have the behaviour explained in light of AG scoping.  If you want to learn
about shared ODPs, please open a new thread.

Program activations.  A program in a NAG stays active until the AG is
destroyed.  This is important if you do RETURN with LR off.  If you use
RETURN with LR off, post a note to this thread to have this behaviour
explained in light of AG-based activations.  If you want to learn about
RETURN with LR off, please start a new thread.

So, my "baby step" strategy is this: DFTACTGRP(*NO) ACTGRP('QILE') under
these conditions:
a) No shared ODP
b) Overrides issued by OPM
c) LR always on at program end

When the inevitable response comes talking about performance, carefully
weigh this important fact: your current environment has no shared ODP and
LR
is always on.  That's the worse-case performance scenario.  The easiest to
program, but worst performing.  A single named AG per job is not going to
make that noticeably better or worse.

Here we go!

  --buck