AGs and subprocedures and service programs, oh my

I am (still) developing a strategy for our group to start using subprocedures 
and, from that baby
step, service programs.  The big concern raised in my shop thus far is that 
programs using
subprocedures are not allowed to be compiled with DFTACTGRP(*YES) and, so, what 
are we getting
into when we start running things that are not in the default AG.  Astute 
listers may recall the
thread I started in January titled "Why do procedures require DFTACTGRP(*NO)?"
(http://archive.midrange.com/rpg400-l/200301/msg00013.html).  Unfortunately I 
got sidetracked with
"real" work, but now I have been asked to investigate this further.

Thankfully, due to Jon Paris' clever catch on our current usage of modules, I 
have been able to
state that, since we are already compiling modules and using CRTPGM to bind 
several of these
together, we are already running ILE programs that do not use the default 
activation group but run
in the QILE AG.  Therefore, there is nothing "new" about running outside the 
default AG.

Knowing that the group was not going to be entirely satisfied with just that 
answer, I have
attempted to get a better understanding of AG concepts.  I have checked the 
archives, the FAQ, the
info center, the ILE Concepts reference, online articles, etc., etc.  Wow, my 
head hurts.  

If it is possible, I would like to understand AG's in a "strict" context of how 
we are going to
encounter them.  By this I mean that, when we take a subroutine and convert it 
into a subprocedure
(in the same source) or convert it into a service program (my ultimate goal) 
and, by doing so,
having to compile so that it cannot be forced to run in the default AG, are we 
opening ourselves
up to problems now that we can't guarantee that it will run in the default AG?  
Can we ensure(?) a
similar environment by compiling with ACTGRP(*CALLER)?

Note that overrides and sharing open data paths are not an issue (maybe).  We 
are talking about
common subroutines that crunch data (common in the sense that all of our 
programs use them).  At
least I don't think that ODPs are an issue.  If a subroutine chains to a file, 
and we convert that
subroutine into a subprocedure or service program, is ODP an issue?

Does that narrow what I need to know about AGs?  

TIA, Dan

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com