× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks Scott, from another perspective on this, if I wanted to be able to recompile the app for some logic changes in the middle of the day, and that app was in a named activation group and was loaded, the new version would not be used for that activation until the HTTP server was shutdown. Any new activation group would load the new version. Do I have this right? The same as in the old model if LR was left OFF on a RETURN. That user keeps using the old application version and new users would get the new version. Difference in CGI world being that a user is the HTTP subsystem job, which could be servicing many many browser requests, not the browser user making the request. And in CGI world since there are multiple CGI jobs in the HTTP subsystem one request from "user A" could hit the old versions of the app and the next request from "user A" could hit the new version of the app (assuming no persistence is setup).

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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.