Re: embedded sql halt and sql dump

interesting... machine recently upgraded to v5r3 and
we are getting usage limit msgs at qsysopr "often"....
they have not updated license keys yet.
jim

To: <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, January 03, 2006 2:29 PM
Subject: Re: embedded sql halt and sql dump

usage limit on sql perhaps?

-----Original Message-----
From: Jim Franz <franz400@xxxxxxxxxxxx>
To: MIDRANGE-L@xxxxxxxxxxxx
Sent: Tue, 3 Jan 2006 13:47:43 -0500
Subject: embedded sql halt and sql dump


Has anyone else seen this halt ?

i have no authority at this customer to start an IBM Service call, and can see

already the ptf cume level is one level back.
However, program has been running for many months.
OS400 V5R3 ptf level c5207530 and db group 99503 level 6
SQLRPGLE compiled at release V5r2 for prev release V5R1
Very basic  select statement

SELECT * FROM IVRCYTD WHERE RCRQTY<>0 and RCIVCD <> 'N' and RCDATE> 20051226 ORD

ER BY RCCONO,RCDIV,RCLOC,RCIVDP,RCPART,RCCOND,RCICNO
(i did cut & paste this select into strsql & it runs fine)
dump values:
SQLCOD  -901

SQLSTT 58004 (in Info Center as "system error") and produced a qsqlsrv dump

report in qezdebug

No indication (I can see) and "what" system error, but joblog (below has some

info).

I beleive the sql error occurred "after" a record was read, because program dump

was at a statement
inside this loop         dou       SqlCod     <> *zero

Program dump does show all field values of selected record as zero and blank.

Pgm was missing a statement like c/exec sql whenever sqlerror go to xxx

SQL0901    Diagnostic              50   01/02/06  22:39:01.818160  QSQRUN2
QSYS        *STMT    QSQRUN2     QSYS

From module . . . . . . . . : QSQFETCH

From procedure . . . . . . : CK_DEBUG

                                    Statement . . . . . . . . . :   14360

To module . . . . . . . . . : QSQFETCH

To procedure . . . . . . . : CK_DEBUG

                                    Statement . . . . . . . . . :   14360

                                    Message . . . . :   SQL system error.

Cause . . . . . : An SQL system error has

occurred.  The current SQL
                                      statement cannot be completed
successfully.  The error will not prevent
                                      other SQL statements from being
processed. Previous messages may indicate
                                      that there is a problem with the SQL
statement and SQL did not correctly

diagnose the error. The previous message

identifier was *N. Internal error

type 3943 has occurred. If precompiling,

processing will not continue beyond

this statement. Recovery . . . : See

the previous messages to determine
                                      if there is a problem with the SQL
statement. To view the messages, use the
                                      DSPJOBLOG command if running
interactively, or the WRKJOB command to view
                                      the output of a precompile.  An
application program receiving this return

code may attempt further SQL statements.

Correct any errors and try the
                                      request again.


jim franz
--

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.