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

Dan wrote:

>"What are we getting into when we start dealing with
>new activation groups?" I am asked.

Since I'm the main troublemaker for this topic, I'll kick my opinions in
again.

Check the archives, especially
http://archive.midrange.com/rpg400-l/199904/msg00095.html
http://archive.midrange.com/rpg400-l/199904/msg00100.html
http://archive.midrange.com/rpg400-l/200203/msg00130.html

Also, read the RPG IV Redbook and the ILE Concepts manuals (links in the FAQ
at http://faq.midrange.com.)

Basically, you're 'getting into' a slightly more complex environment, much
like using external DDS instead of I and O specs.  The whole ILE concept
allows for VERY complex scenarios, but for most of us, we will never use the
full power that ILE activation groups provides.  For instance, there is a
reasonable argument to be made for one single named activation group if you
are blending OPM and ILE.  There are other reasonable arguments (especially
see Scott Klement and David Morris' posts for some excellent discussion for
the other major alternative: Front line menu programs=*NEW and all
else=*CALLER.)

>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.

Thanks to Jon Paris for synthesizing a complex topic into a reasonable
space:
If the override is issued by OPM, it percolates into all AGs.
If the override is issued by ILE (AG), it is only visible to other programs
in the same AG.
This is the default behaviour.

>Before I go any further, I should explain that we use
>RPG modules extensively here...

'Module' means something very specific in ILE and I suspect you have a
different meaning.  Do you mean small, callable programs?  Code included via
/COPY?

>Ideally, I would turn this inline subprocedure
>into an external procedure, to keep it out of the
>application source completely.

More important is the idea that once I build a function and put it in a
service program, the same exact code can be called from many places.  This
means that if you find a bug, you fix it in one place and all the callers
use the fixed code.

>"Why is this a subprocedure and not a subroutine?" I am asked.

1) I can reuse the same function more readily than a subroutine
   because a subroutine has GLOBAL scope, whereas a subprocedure
   has local scope.
2) Subprocedures can be used to extend the language like a BIF.
   This leads to more modular thinking, which leads to better code.

I can't stress the thinking part enough.  If I think like an RPG II
programmer I will be writing RPG II programs no matter what syntax of the
language my source member claims to be.

>Someone else in the group mentioned that he thought he'd heard that
>procedures carry a performance penalty when compared to subroutines.

All performance issues should be answered with 'it depends.'  My very strong
advice is to code your 'function' several ways and actually measure it using
your data on your machine in your typical environment.  Use PEX to gather
statistics if possible.

>From a theoretical standpoint, it is probably true that a subroutine is
nanoseconds faster than a subprocedure but I bet you will not notice the
difference in practical terms.  For instance, I use subprocedure calls in a
program where I process several tens of millions of records.  Each record
calls something like 10 subprocedures.  Runs very fast for me even on a 510.
http://archive.midrange.com/rpg400-l/200203/msg00125.html

Apologies to Barbara Morris for my theft and misuse of her quote: Focusing
on subprocedures' overhead is like using a step stool to get closer to the
moon.
  --buck