RE: QZDASOINIT and Persistent Programs

Mike,

I can't promise this, since I don't know how the stored-proc internals
work, but I think you're seeing a variation of the following problem:

Given : Program A call Program B 

If you look at the generated MI for the call to program B from program
A, you'll see the following:

Declare p as pointer

If P = null
        P = GetAddressOf(Program B)
EndIf

CallViaPointer(P)


So here's the problem, on the first call P is null, so the system finds
the address of program B and caches it. However, on subsequent calls, P
already has the address of program B, so the system skips that step.
Well, you can put a new program B in production, however, it's at a new
address. Program A still has the old address cached, and calls the
program at that old address.

This is good and bad. It's good because this is what enables
REPLACE(*YES) on compiles. The Compiler moves the old version of the
program into QRPLOBJ and renames it, but neither of these operations
changes its address, so any jobs that already have a reference to the
old version continue to run. However, any jobs that don't have a
reference yet get a reference to the new program. Cool. But, it's bad
because you can't replace the program and have jobs running get the new
program. BTW, this is also why you get a "Tried to refer to destroyed
object" if you delete the old program instead of replacing it. The
cached pointers are pointing to an address where there is no longer a
program and Boom!

I think you've hit this. The system has probably cached the address of
the old program, so even though you replace it, you can't force the
system to purge those cache entries. However, the cache entries should
only be valid for the job. If you end the QZDASOINIT jobs, the new ones
that pop up in their place won't have the cached address, and will
resolve to the new instance of the program.

However, if you just end these jobs on the iSeries, the connections you
have in VB and Domino won't be valid. How does your VB and Domino app
handle an invalid connection? If it simply attempts to reconnection
you'll be fine, if it goes boom you'll have to do something to account
for the lost connection.

-Walden



------------
Walden H Leverich III
President & CEO
Tech Software
(516) 627-3800 x11
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com 

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
 
-----Original Message-----
From: midrange-l-bounces+waldenl=techsoftinc.com@xxxxxxxxxxxx
[mailto:midrange-l-bounces+waldenl=techsoftinc.com@xxxxxxxxxxxx] On
Behalf Of Michael Naughton
Sent: Thursday, 09 September, 2004 21:10
To: Midrange Systems Technical Discussion
Subject: QZDASOINIT and Persistent Programs

Hi everyone,

I'm having trouble coming up with a catchy description of this problem,
so
here's the scenario:

We have a VB and Lotus Domino programs that call stored procedures on
our
AS/400. The jobs (QZDASOINIT) run in QSERVER with the user name of the
DSN
we're using for the ODBC connection.

We've found that if we change the stored procedure (SQLRPGLE program) on
the AS/400, the VB programs don't seem to pick up on it right away. They
seem to keep using the old version -- maybe until a system IPL, maybe
until the Domino server reboots (we don't do this very often, and
everything is in production, so it's a little hard to run extensive
tests).

Has anyone else experience with this? Is there a way to stop this from
happening (i.e. to recompile the program the program on the AS/400 and
have the stored procedure recognize it [maybe use UPDPGM instead?]). In
the spirit of RTFM, I'd be  happy to, if someone could point me to where
the FM might be found. . . . :-)

Thanks very much for any help

Mike Naughton
Senior Programmer/Analyst
Judd Wire, Inc.
124 Turnpike Road
Turners Falls, MA  01376
413-863-4357 x444
mnaughton@xxxxxxxxxxxx

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