Re: ODBC (?) Problem - Finished Job Producing Output

This is not the only job that stays running across IPL's.  If you do a 
SNDNETSPLF from one iSeries to another (not on the same iSeries - it works 
different!), then you'll use the same job number.  Could be one of the 
reasons they increased the number of spool files per job.  To reset this 
is quite easy.  If you ENDJOB *IMMED DLTSPLF(*YES) then it will delete all 
spool files associated with that job and use a different job number the 
next time.  And it will free up some spool file storage if that job has 
thousands of spool files; deleted or still active.

That's only part of your problem.

The other has me a little confused.  Is the ODBC application still calling 
the stored procedure on the iSeries?  Let me come up with a hypothesis and 
then let's chase that one down.  My hypothesis is this:  When you changed 
the program, perhaps you modified the parameter list.  In doing so you are 
running into something called "overloading".  You can have multiple stored 
procedures, in the same library, all calling different programs.  And the 
system picks one based on the parameter list.  Check out your list of 
stored procedures by:
RUNQRY QRYFILE(QSYS2/PROCEDURES)
Perhaps the stored procedure is calling an older version of the program in 
some obscure library, like maybe QRPLOBJ?
You might look at recreating the procedure with sql's DROP PROCEDURE / 
CREATE PROCEDURE combo.

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin 





"Michael Naughton" <mnaughton@xxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
08/11/2003 09:10 PM
Please respond to Midrange Systems Technical Discussion
 
        To:     Midrange Systems Technical Discussion 
<midrange-l@xxxxxxxxxxxx>
        cc: 
        Fax to: 
        Subject:        ODBC (?) Problem - Finished Job Producing Output


I'm not sure if this is the right list or not - this one has me stumped. 

We've got a Notes/Domino application that calls a program on the AS/400
using stored procedures and ODBC (I think I have that right - I'm not the
expert on that end). The AS/400 program (SQLRPGLE)  A does some things and
then calls another program B that produces a printout. So far so good -
everything has been working fine for a while.

Today, I made a change to program A so that it will write a log record
every time it's called. After I put it into production, I found that
printouts were being produced, but no log records were being written.
There's (always) the possibility of a program bug, but it's a pretty
simple program, and it writes the log right before calling program B.

Looking into it further, I discovered that the spool files that program B
is producing all think they're coming from a job that started back on
January 9th. This job is running under the profile that is used for the
ODBC connection. Most of the spool files are gone - printed & deleted -
but a few are still around (including today's), and they clearly go back
several months. So my first thought was that this is an active job that
was using the old version of program A, and if I simply ended and
restarted it everything would be fine.

Now comes the part that has me stumped: the job isn't active. It doesn't
have a job log, because it thinks it ended (although WRKJOB shows a start
time but no end time). It doesn't show up in work active jobs, and when I
try to end it it says it's already ended.  But, clearly, it continues to
produce spool files, as it has been doing for many months. We IPL every
weeek, so it's survived multiple IPLs (apparently). Domino is running on
an NT box (please, don't go there :-), and it also has been rebooted
several times recently. 

Does anyone have any clues? Any ideas about how I might debug this? Any
thoughts will be greatly appreciated!

TIA,

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.