Re: ILE questions: activation groups, rpg-cgi, classic web server.

I'm by no means an expert, but I do remember the discussion a while back,
and I found it very interesting. The main thing I remember getting from it
was, "keep it simple", meaning that unless you have a really good reason
for  using some of the more powerful (read "dangerous") features of
activation groups, don't bother. Depending on your environment, the
advantages of using named activation groups and having them stick around
after the program has ended may or may not be outweighed by the
disadvantages -- most of us are pretty used to having certain things
"start fresh" when you run a new program, and using named activation
groups blows that assumption away.

I'm not sure what's meant by "default" activation group, but I regularly
convert RPGIII code to RPGIV and convert some (or all) of the CALLs to
CALLBs (yeah, yeah -- I know I should be doing procedures; I'm working on
it!) and then run the resulting programs in the same jobs as RPGIII
programs. I never specify activation group, so I assume I'm using *NEW,
and as far as I know I've never had a problem. If I want PgmA to call PgmB
a lot of times, I make it a CALLB, and that seems to give me at least most
of the advantages. Performance is the same as with all the other programs,
which means sometimes better than others but always acceptable unless
there's some sort of problem with the system.

My impression is that the next step would be to write procedures and put
them into service programs and then compile the service programs to run in
*CALLER.  Based on what I know so far, I'm not sure that named activation
groups are anything I will use in the foreseeable future. I think they are
good for certain situations, but as far as I can tell they don't really
offer much in most environments, especially now that memory and processor
power are getting so cheap. I know that sounds wasteful (I started
programming twenty years ago on a system that required me to keep all my
programs under 32K in size, and they had 56K of memory to run in!), but
most programs on most systems are going to run fast enough no matter what
you do, and spending a lot of time and effort trying to squeeze a few more
milliseconds out of them may or may not be a good business decision for
the people who sign  your paycheck.

JMHO,

rpg400-l@midrange.com writes:
>Richard,
>
>If you use the default activation group, static binding and binding
>directories are not
>supported.  This also means CALLB and CALLP aren't supported, nor are
>procedures (which are statically bound, hence unsupported by
>dftactgrp(*yes)).
>
>If you're doing a conversion, DFTACTGRP(*YES) lets you make your RPGIV
>programs act like RPGIII programs, which means you can use CVTRPGSRC and
>easily "upgrade" (if that's the right word) to RPGIV.
>
>When using static binding, then you'll have to specify a named
>activiation group, or
>*NEW.  You can also use *CALLER to use the caller's activation group, but
>if the
>caller's activation group is the default activation group, static
>binding, callp, callb, etc.
>won't work.
>
>What you use depends on what you want to do, or perhaps what functions
>you need
>support for...
>
>I think RPGIV presents a lot of very powerful options, particularly with
>prototyping
>and binding, that we can take advantage of, but that requires using named
>or
>temporary new activation groups.
>
>I don't think I'm knowledgeable enough yet to comment intelligently about
>the
>advantages of *NEW as opposed to QILE or a named group, but a lot of very
>smart
>people watch this list....maybe somebody will weigh in?
>
>--Chris



Mike Naughton
Senior Programmer/Analyst
Judd Wire, Inc.
124 Turnpike Road
Turners Falls, MA  01376
413-863-4357 x444
mnaughton@juddwire.com