× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.