Does LR being on or off when the program returns have anything to do with the activation group? Does an activation group still exist even if there are no "open" RPG applications?
(e.g. I call a program with a named activation group (SCHEDULING). The activation group is created, the app runs, the app sets on LR and returns. Does the activation group SCHEDULING still exist so on the next call that process does not need to be repeated?
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Monday, October 15, 2007 12:27 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] ILE RPG CGI and Activation Groups
Mike,
If you leave your files open and change your programs to run in a *caller activation group you'll get the best performance, generally. But in my experience the overhead of closing and reopening files is not as significant as the overhead of creating and deleting activation groups.
On the con-side that keeps your programs active and your files open and you never know how many instances of your programs may be active at any given point in time supporting the CGI interface. Under the green-screen interface the files are closed and activation groups deleted when users exit the mainline program, but under the CGI interface every instance of the application that is activated over time remains active until the HTTP server is shut down, so you and your users loose some control over when resources are allocated and cleaned up. This is my main reason for bypassing the CGI interface in my Web application architecture, but most Web application developers don't have to deal with overall system management, and therefore don't put much effort into it.
Nathan.
----- Original Message ----
From: Mike Cunningham <mcunning@xxxxxxx>
To: "web400@xxxxxxxxxxxx" <web400@xxxxxxxxxxxx>
Sent: Monday, October 15, 2007 8:29:37 AM
Subject: [WEB400] ILE RPG CGI and Activation Groups
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. I have a ILE RPG CGI app that does no
database work or business logic. It only does the CGI work to present
the HTML code. The CGI calls (no not CALLB or CALLP just old fashion
CALL) another RPG app that does all the work unique to this application
but the called RPG app also calls a bunch of other RPG apps that also do
some database work and business logic. All of these called apps are
also used by older green-screen applications so the business logic is
shared between web users and traditional users (Yes I would like to get
them all on the web frontend but that might be some time before I can
accomplish that).
From what I have read I think the activation group setting on the CGI
app should be a named activation group or *CALLER, anything but *NEW.
In am not sure now to set the activation group for the called RPG and
all the second lever called RPGs that are used both from Web and
green-screen apps so as to make web response the best it can be but not mess up
green-screen users. And I am not sure of the *INLR setting I should
use. Currently the non CGI called RPG is setting on LR after every call.
It does explicate OPENs on all the files it needs to fill the request
but it does not do any closing, assuming the *LR = *ON will close
everything. Same with the second level called apps. They all have a shut up
switch that can be passed in which causes the app to seton LR and
shutdown. In green-screen mode these are all opened on first call and then
shutdown when the user exits the main application. In CGI mode these are
all shutdown after each request (if it was used on that request).
I know this has to be having some negative impact on the web response
but I have not see any real speed issues but I have only tested with
about a dozen users at one time and soon that will ramp up to about 300
users at one time when students start to schedule classes.
--
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
