Why do procedures require DFTACTGRP(*NO)?

[Dan <dbcerpg@xxxxxxxxx>]

Boy, not a great way to start the new year!  Not 15 minutes after I get
in today, one of the project managers wants to know why a program I
wrote two months ago requires DFTACTGRP(*NO) in the compile.  I explain
that the program uses a subprocedure and, as such, requires
DFTACTGRP(*NO).  "What are we getting into when we start dealing with
new activation groups?" I am asked.  I stutter, mumble, explain that I
am not very knowledgeable in AGs, but that I have been using
DFTACTGRP(*NO) for several years now with no ill effects.  Of course,
my usage of this has never crossed into overrides and some of the other
“gotchas” I’ve seen discussed on this list before.  The only two unique
instances that I’ve found I’ve had to use it is 1) for subprocedures
and 2) for programs that may already be in the program stack when it is
called again.

Before I go any further, I should explain that we use RPG modules
extensively here and it has greatly simplified some complex stuff they
do here.  We try to adhere to the "code once, test once, don't touch it
again" practice.  However, as I am a relative newcomer here, I am the
first to introduce subprocedures, and they are willing to embrace it if
they can see a benefit.  Ideally, I would turn this inline subprocedure
into an external procedure, to keep it out of the application source
completely.

"Why is this a subprocedure and not a subroutine?" I am asked.  I
stumble through a few benefits as I try to clear the New Year’s fog in
my head.  Isolating variables in a procedure, keeping the numerous
D-specs in the procedure, helps keep the application code cleaner and
easier to read.  Eventually want to move it out of the application’s
source completely and into an external procedure.

Someone else in the group mentioned that he thought he’d heard that
procedures carry a performance penalty when compared to subroutines.  I
can’t answer that definitively, although I don’t remember it being an
issue.

So I’m off to a shaky start in 2003.  Any help with these issues and/or
pointers to online articles would be greatly appreciated.

TIA, Dan

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com