RE: Activation groups for beginners

Synopsis:

1) Programs that run in the same AG
   implicitly share resources.
2) Shared resources include overrides,
   commitment control, static storage,
   Open Data Paths, SQL cursors
   (there's more but these are the common ones.)
3) There is no single "best" AG strategy.
4) AG strategy is part of the overall application
   design - see 1 above.

If you "own" the application from the initial menu selection onwards, then
having the initial menu selection be *NEW and all other programs in the
application be *CALLER is an excellent strategy.  This would let the system
assign a unique name to each application (here, A/P, G/L, P/R, etc.)  So the
very first G/L program runs in *NEW.  The system creates a new uniquely
named AG.  That program then calls everything else (it could be the G/L main
menu).  Since everything else is *CALLER, all the other G/L programs (off
that menu) run in the same AG as the G/L menu.  You don't have to worry
about name clashes (did I pick an AG name that somebody else picked?).  You
do need to think about cross-application sharing.  If the G/L system calls
an A/P program, should the A/P program run in the G/L AG?  It depends if
your code expects to share resources or not.

If you are converting programs one at a time AND you have a simple
environment, you can't be sure that your ILE program gets called from a NAG.
Having all of these programs run in a single NAG can make it easier to
deploy these because the default scoping rules will let the ILE NAG program
obey the overrides issued from *DAG.  So an OPM CL that does an OVRPRTF then
CALL ILERPG AG('MYCOMPANY') will work just like  OPMRPG did.  The downside
to this is that there's very little flexibility - when you finally write a
true ILE application where the programs expect to share resources this model
won't allow that.  But you can use *NEW/*CALLER in that scenario.

If you are converting programs one at a time AND you have a complex
environment, we haven't talked about your life yet!