Re: Named Activation Groups -- RPG400-L

Hi Alan,

> The company is mostly running RPGIII code written in RPGIV.
> I write almost 100% subprocedure with heavy use of service
> program which I am catching a lot of flak. The company has
> some service program but a lot of the service program are
> written using *ENTRY Plist's instead of procedures and a
> lot of modules statically bound into programs.
> Most programs are written in RPGIV but coded as if RPGIII.

Let me re-state this so you're sure I understand your situation.  Most
of the existing service programs are called via CALLB (and could just
as well be invoked with CALL.)  You're trying to create a library of
functions invoked by CALLP or EVAL and you want to be able to
integrate this as seamlessly as possible within the existing OPM
structure.  Please correct any misunderstanding I have!

In this scenario, you probably don't have a sophisticated application
design, where files are left open across multiple programs in the job
stack.  In this case, you probably don't need multiple activation
groups to segregate open files from each other.  In fact, having
separate AGs may be problematic, depending on the overrides being
issued.

Here is my input.  It is only something to chew on, and not intended
to be an absolute 'this is the right way' ruling.  As I said earlier,
there is no one right way; it depends deeply on your design strategy.

If you can identify the top level programs, make them *NEW and all
other programs and service programs *CALLER.  This is easily the most
common recommendation.

If you can't implement that strategy (quite possible in a mixed
environment of OPM and ILE) consider a single named activation group.
Call it the same as your company name if you're worried about somehow
clashing with third party software which may use QILE.  Create a /copy
member called (for example) STDHSPEC and put your H-specs in there.
DFTACTGRP(*NO) ACTGRP('MYCO')  Then use /COPY to bring that into every
RPG IV program.  This way you won't have to remember to specify it on
the compile itself.

For service programs, the typical recommendation is *CALLER, but if
there's a chance that there are RPG IV programs running in the default
AG, then the service program would get activated there,  too.
Reclaiming that means ending the job.  If you can guarantee that all
ILE programs run outside the DAG, use *CALLER on your service
programs.  That way they will activate properly no matter what AG the
caller is in.  If you can't guarantee that the caller is outside the
DAG, create the service programs in ACTGRP('MYCO') as well.

The downside is that if you ever decide to really want to use
activation groups for real, you're going to be doing a lot of
re-compiles and testing to make sure things still work.  The upside is
that there aren't any decisions to make.  All RPG IV programs are
compiled the same way.

The biggest unknown to consider is overrides.  If you issue overrides
in OPM, then a single named AG strategy will work very well.  (Watch
OPNQRYF though.)  That's because ILE can see overrides issued by OPM.
If you issue overrides in ILE, then OPM will not see them, and you'll
have a mess.

I hope this helps a bit.
  --buck