RE: Activation groups for beginners

[Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>]

First, "What's an Activation Group?"

Activation groups are a new feature of the ILE (Integrated Language run time
Environment.)  They allow the application designer to subdivide a job into
separate areas involving memory and overrides (like OVRDBF and OVRPRTF.)
They are required if you want to use subprocedures in your programs.  There
are some technicalities to that, but that's the Big Picture.

Many people have expresses concern for the complexities of AGs, so  we're
kicking this thread around to see if we (the folks using AGs) can clear up
some of the concerns for folks just coming up to speed in ILE.

If you're curious about AGs, catch the beginning of the thread in the
archives and jump in with questions - this is all about you!


Next, continuing the discussion...

>I think the most common scenario faced in
>most shops that have evolved over many
>years of development is to have a majority
>of programs that were converted from RPGIII,
>with very little change, into OPM RPGIV
>and running in the *dftactgrp.  Now, new
>programs are being written in ILE and many
>(or most) of them are called by these older
>OPM programs which have not been changed to ILE.
>So the question is how these called "new"
>ILE programs should set their activation group.

There's room for honest disagreement here, but fundamentally RPG IV running
in the DAG is the same as OPM, so I'm not going to quibble.  I'd say your
analysis is plenty good enough.

>If we use *CALLER, they get stuck into the OPM calling
-snip-
>*NEW is ok programs that are not called repeatedly,
-snip-

Once again, I'm really trying to focus very tightly on the simplest scenario
- in fact, the one you outline above.

OPM calls ILE
  No shared ODP
  Overrides in OPM
  No RETURN without LR on

My suggestion is to use ACTGRP('QILE')
My reasoning is that there's no reason to subdivide such an application into
AGs because there's no benefit.  Has anyone had bad experiences with a
similar arrangement?  I haven't.  Here's an example:

CLP AG(*DAG)
  OVRDBF MASTER MBR(MAR)
  CALL PRINT, AG('QILE')
    System activates program
      Allocate/init static storage
      Complete binding to service programs
    Open MASTER, mbr(JAN)
    ...
    Close MASTER
    SETON LR - program still activated in AG('QILE')
  CALL OPMUPDATE, AG('QILE')
    Open MASTER, mbr(JAN)
    ...
    Close MASTER
    SETON LR
  CALL PRINT, AG('QILE')
    Program is still activated!
    Open MASTER, mbr(JAN)
    ...
    Close MASTER
    SETON LR - program still activated in AG('QILE')
ENDPGM

/* AG('QILE') is still in existence for this job */
/* OVRDBF to MASTER is gone, since the CLP issuing it ended */

CLP AG(*DAG)
  OVRDBF MASTER MBR(SAV)
  CALL PRINT, AG('QILE')
    Program is still activated!
    Open MASTER, mbr(JAN)
    ...
    Close MASTER
    SETON LR - program still activated in AG('QILE')
ENDPGM

/* AG('QILE') is still in existence for this job */
/* OVRDBF to MASTER is gone, since the CLP issuing it ended */

Job terminates, AG('QILE') for this job terminates too.

The override from the OPM carries into AG('QILE') so there's no real concern
on that score.  The print program doesn't use static storage so that's no
concern either.  Does anybody need actual code they can compile, or would
you prefer to write some simple stuff in your own familiar environment?

Remember, this is supposed to be an interactive, progressive discussion,
from simple (today) to full-featured (later on.)