RE: Why do procedures require DFTACTGRP(*NO)?

Sounds like they want to start burning witches. LOL!
Or better yet, they have a case of mainframe-itis.

Use just DFTACTGRP(*NO) means you're probably running in QILE. If you
always do this, then ever RPG IV program you right will run in QILE and
have similar results to those that run in the default activation
group--provided they are not being called in a long list of non-ILE
programs, that is if everything runs in QILE, then it works pretty must
like the default activation group except for overrides and file opens,
but you can fix that by doing a OVRSCOPE(*CALLLVL) to get the dftactgrp
effect. But most people like the new default better anyway.

In general, mixing programs in an activation group with old default
activation group programs can cause issues with overrides, but other
than that, there isn't much more to worry about.  Now, calling CL
programs from QILE that do overrides and if those CL programs are
running in dftactgrp, then you have the quintessential cause for Witch
burning.

Bob

-----Original Message-----
From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]
On Behalf Of Dan
Sent: Thursday, January 02, 2003 9:37 AM
To: rpg400-l@midrange.com
Subject: Why do procedures require DFTACTGRP(*NO)?


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
_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@midrange.com To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.