RE: QZDASOINIT and Persistent Programs

Walden's description definitely rings true.

Couple of things to consider:
1) if using embedded sql you can try compiling program with CLOSQLCSR
parameter set to *ENDMOD versus *ENDACTGRP
2) what OS release you're at?  On V5R1 and up IBM's QSTRUP program added
STRSBS QUSRWRK to it, and that's the preferred subsystem for running ODBC
jobs (qzdasoinit).  If these jobs are running under QUSRWRK, then they're
running as prestart jobs and by default they're reused 200 times before
being ended by the system.  To end prestart jobs, there are ENDPJ and STRPJ
commands.  This does not apply to your current setup.
The fallback mechanism is to resort to legacy setup, namely batch immediate
jobs (BCI) in QSERVER.  
The fact that you're running in QSERVER may actually work to your favor as
you can simply end any active QZDASOINIT jobs that you know are using your
stored procedure, ensuring that any newly started jobs will pick up your new
version of the program.
3) delete the program before recreating it.   This will force active ODBC
connections that invoke your stored procedure to fail (not graciously at
all!) and any new ones should work fine.

HTH.

Elvis


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich
Sent: Friday, September 10, 2004 8:31 AM
To: Midrange Systems Technical Discussion
Subject: 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.


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