If you create an RPGIV program with CRTBNDRPG and DFTACTGRP *YES, an OPM
program is generated, i.e. when ending the program with *INLR = *ON, it is
removed from memory after the program ends. The next time the OPM program is
called within the same job the new version of the program will be activated.
ILE programs are NOT removed from memory when ending with *INLR = *ON. They
remain in the activation group and only the files get closed. At the next
call, the variables are reinitialized and the files reopened, that's it. An
ILE program is not removed from memory before the activation group in which
it runs is ended.
When running an ILE Program in the default activation group (due to the
issue that is was compiled with activation group *CALLER and the caller
program runs in the default activation group), the program will not be
removed from memory independent whether it is ended with *INLR = *ON or NOT.
It will not be replaced before the job ends, i.e. until the default
activation group gets closed.
Because it is a web application, your program may or may not run within the
same job. If it runs for the first time in a different job, the new version
will be executed.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
-----Ursprüngliche Nachricht-----
Von: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Jeff
Young
Gesendet: Friday, 20.11 2015 21:47
An: Midrange Systems Technical Discussion
Betreff: Re: Stored Procedure called from Web Process
Vern,
Yes, I understand that, but my question was if the pgm being replaced is
called via a stored procedure, when the pgm ends with *inlr on, does the
stored procedure get cleaned up so that if another call to the stored
procedure uses that same job (i have no control over which job is used as it
is called from a web pgm) should it get the replaced pgm or the new pgm?
if it were a case if an interactive job, and the pgm was called from the
command line, when the pgm ends with *inlr on, the next call from that job
would get the new program.
My question is should I expect the same behavior when called from a web pgm
and one of the QUSRWRK jobs gets control?
Jeff Young
Sr. Programmer Analyst
On Fri, Nov 20, 2015 at 3:15 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:
Hi Jeff
Jobs using a program that has been changed will use the one in QRPLOBJ
until the job ends. This is a bit of wizardry the system does, so that
jobs don't blow up because a program has been changed. I suspect that
the *PGM object, which has a certain address in memory, is mapped to
the new library
- the job has resolved it to its pointer, so it doesn't matter anymore
what its name is and which library it's in - a library is just a list
of objects, after all. Sort of!!!
HTH
Vern
On 11/20/2015 1:01 PM, Jeff Young wrote:
All,
I have an RPGLE program that is being called via an SQL Stored
Procedure from a web process. This program does some work and returns
with *INLR on.
The program currently specifies DFTACTGRP(*NO) ACTGRP(*CALLER) in its
attributes. If I change this program, the prior version is placed in
QRPLOBJ as it should. However, sometimes, one of the web processes
gets the QRPLOBJ version of the program.
Is this due to it not being in a named activation group, or could
there be another reason.
Jeff Young
Sr. Programmer Analyst
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
