Re: ILE RPG CGI and Activation Groups

[<matt.haas@xxxxxxxxxxx>]

I use *CALLER for the most part and the only time I have to restart the
HTTP server is when service programs are updated. It's worked this way
since the HTTP server came out in the V3 days.

Matt

-----Original Message-----
From: web400-bounces+matt.haas=cengage.com@xxxxxxxxxxxx
[mailto:web400-bounces+matt.haas=cengage.com@xxxxxxxxxxxx] On Behalf Of
Jeffrey Flaker
Sent: Tuesday, October 16, 2007 6:12 PM
To: 'Web Enabling the AS400 / iSeries'
Subject: Re: [WEB400] ILE RPG CGI and Activation Groups

I have recompiled programs and used them without restarting the server.
Only, my programs are using ACTGRP(*NEW), so this may be like comparing
apples and oranges.  Maybe this is another "advantage" of
ACTGRP(*NEW)????
Maybe.

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On
Behalf Of albartell
Sent: Tuesday, October 16, 2007 1:34 PM
To: 'Web Enabling the AS400 / iSeries'
Subject: Re: [WEB400] ILE RPG CGI and Activation Groups

I don't know the exact details, but here is my take based on what I have
found.  

The *PGM object being called from the browser is holding onto an
"instance"
of the *SRVPGM.  If the *SRVPGM is recompiled, the *PGM doesn't get the
new
version until the *PGM object is also re-compiled or the instance is
restarted.  I run into this a lot with XML web services in RPG.

With that said I do not have a thorough understanding of how RPG objects
are
stored in memory, and how/when they are replaced.  Anybody expound on
that
subject?

Aaron Bartell
http://mowyourlawn.com


Mike Cunningham wrote:
> 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).