Thanks Jeffrey, that was one of the articles I had search and read. It did help me understand.
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Jeffrey Flaker
Sent: Monday, October 15, 2007 6:36 PM
To: 'Web Enabling the AS400 / iSeries'
Subject: Re: [WEB400] ILE RPG CGI and Activation Groups
There is a good article on activation groups. You will either think it
makes things clearer or it will become as clear as mud as I heard on another
group.
HYPERLINK
"
http://www.itjungle.com/fhg/fhg021104-story01.html"http://www.itjungle.com/
fhg/fhg021104-story01.html
As difficult as it is to explain, it is really a simple concept.
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Scott Klement
Sent: Monday, October 15, 2007 4:12 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] ILE RPG CGI and Activation Groups
hi Mike,
I have been reading up on activation groups and how they relate to
CGI apps. I understand the concept but I have a design issue that I
can't see having been discussed as yet.
For me, I tend to think of my programs (or *SRVPGMs) in two different
categories:
a) Initial programs (Called directly from the command-line, menus, CGI, etc)
b) Sub-programs or service programs. These are never called directly
from a menu or command-line, but are called by other programs.
Note that whether you're using CALL, CALLP or CALLB really doesn't
matter. They all work the same way... Initial programs should either
use a NAMED or *NEW activation group. Sub-programs should always
(well, almost always) use *CALLER.
The next question is really how do you want things to behave? If you
want programs to ALWAYS leave their resources open, including files,
variables, etc. Then you should use a NAMED activation group for the
initial programs. This way, they'll remain loaded into memory. If you
leave *INLR=*OFF, they'll also leave their files open, etc. This has
the best performance, since most startup tasks only need to be done once.
On the other hand, if you want all of the resources to be automatically
cleaned up when the initial program ends (including all resources used
by all sub-programs) then use ACTGRP(*NEW), and (no matter if LR is on
or off) it'll close all files, free up all memory, and unload all
programs from memory (including the sub-programs).
Because of all of the extra work involved in opening & closing files,
loading/unloading programs from memory, etc, ACTGRP(*NEW) doesn't
perform as well. The performance difference doesn't matter if the
program is only called once or twice. But if it's called many times,
the performance will become significant.
Since most CGI programs require many, many calls to get the job done,
most CGI programs lend themselves to using a named activation group. If
you need to close the files, etc, when you perform a backup (or
something like that) you can always end the HTTP server before your
backup, and then restart it afterwards. That way, you only incur the
performance penalty once...
Hope that helps.
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/web400.
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.14.11/1071 - Release Date: 10/15/2007
6:48 AM
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.14.11/1071 - Release Date: 10/15/2007
6:48 AM
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/web400.
midrange.com
