Re: Activation groups for beginners

You left out *CALLER, which will lead to people writing utility programs
and/or service programs which can't be scoped in with the programs that
call them.   *CALLER is very important.

I also don't think you should teach named activation groups -- although
QILE isn't so bad, it's about the only one I'd ever use.  Trying to make
sure no two programmers pick the same name for their named activation
groups -- and then trying to keep these unique when installing 3rd party
applications -- is a mess.

Use *NEW & *CALLER.   When used correctly (which is easy to to) they yield
the same performance as named groups.  They're more efficient on memory.
They don't leave overrides laying around that can randomly affect other
jobs.  They don't create the maintenance nightmare of named groups.
They're easier to use, and a better solution.

On Mon, 4 Mar 2002, Buck Calabro wrote:

> 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