Re: [Bulk] Re: Stored Procedure called from Web Process

Jeff:

If and only if you code in OPM RPG/400, or in RPGLE with DFTACTGRP(*YES), then setting *INLR to *ON will give the desired behavior.

What IBM calls "DFTACTGRP(*YES)" should really be called "OPMCOMPAT(*YES)" for "OPM-compatible" behavior, because that is what it does; the RPGLE compiler generates some extra code so the program will behave just like an OPM RPG/400 program when it runs in the default activation group (DAG), especially with regard to what happens when *INLR = *ON or when RCLRSC is issued ....

Running in a named activation group will not necessarily help, because you would still need to somehow force the RCLACTGRP command to run for that AG in that job.

You could change the program to ACTGRP(*NEW) and that will force a new AG to be created each time the program is called, and when the program returns / ends, the AG will automatically get deleted (cleaned up) by the OS. So, that should "solve" this particular problem, although incurring some slight additional overhead.

Hope that helps,

Mark S. Waterbury

> On 11/20/2015 4:55 PM, Jeff Young wrote:

Vern,
The stored procedure is the RPGLE program being replaced.
What I am seeing, is even though the RPGLE program returns with *INLR on,
the job in QUSRWRK sometimes gets the *old* program (now in QRPLOBJ)
instead of the new program. Is this an activation group issue or is this
due to web services?
Will running the program in a named activation group resolve the issue?

Jeff Young
Sr. Programmer Analyst

On Fri, Nov 20, 2015 at 4:05 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

Jeff

I'm not sure - Brad's reply suggests that it's best to bounce the servers,
just in case.

I seem to recall that even when a program ends after compiled with
replace(*YES), that the one in QRPLOBJ will be used - it's a job-level
thing, maybe - someone else will need to confirm or refute.

I see the behavior when I use debug, that it is using a different program
than the source looks like - so viewing the listing option points me to the
one in QRPLOBJ.

Just to clarify some language - when you say "called via a stored
procedure" do you mean that another program (the one that implements the
stored procedure) is calling the one you are replacing?

Thanks
Vern


On 11/20/2015 2:46 PM, Jeff Young wrote:

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