DSNT408I SQLCODE = -804, ERROR

[jsquizz]

Hello all,

CMOD 10.5.0.6
Z/OS 4.28.0
DB2 12.01.0005

We are working with IBM on a case related to this. I am wondering if anyone has seen something such as this.

We have a folder that has 6 application groups - One of the application groups has around 160 tables associated with it.

There's a field named "AcctNo"

Via the client - when we run "Account Number" in then in the search box for example 11111 22222 33333 44444 55555, we get the following:

The same happens when I try via arsdoc get or query.

Code: [Select]

DB Error: {DB2 FOR OS/390}{ODBC DRIVER}{DSN12015}   DSNT408I SQLCODE = -804, ERROR:  AN ERROR WAS FOUND IN THE APPLICATION PROGRAM            INPUT PARAMETERS FOR THE SQL STATEMENT, REASON 07                       DSNT418I SQLSTATE   = 07002 SQLSTATE RETURN CODE                                 DSNT415I SQLERRP    = DSNXECP SQL PROCEDURE DETECTING ERROR                      DSNT416I SQLERRD    = -202  0  0  -1  262124  0 SQL DIAGNOSTIC INFORMATION       DSNT416I SQLERRD    = X'FFFFFF36'  X'00000000'  X'00000000'  X'FFFFFFFF'                  X'0003FFEC'  X'00000000' SQL DIAGNOSTIC INFORMATION                      ERRLOC=5:10:2 -- SQLSTATE=07002, SQLCODE=-804, File=arsdoc.c, Line=3526


[Justin Derrick]

Here's some total WAGs:

Check app group definitions to make sure AcctNo has the same definition in all App Groups

If you have database access, something like:

Code: [Select]

select * from arsagfld where name like 'acctNo' will make any differences a little more obvious.

Turn off parameter markers for queries

Ask your DBA to check their diagnostic logs (db2diag.log in the LUW world) for more info.

-JD.

[jsquizz]

Here's some total WAGs:

Check app group definitions to make sure AcctNo has the same definition in all App Groups

If you have database access, something like:

Code: [Select]

select * from arsagfld where name like 'acctNo' will make any differences a little more obvious.

Turn off parameter markers for queries

Ask your DBA to check their diagnostic logs (db2diag.log in the LUW world) for more info.

-JD.

Turning off parameter markers gave us the results I need -> I think. We're able to see the queries and are still investigating.

I've never had to touch that checkbox before. Thanks from myself and my colleagues.

[Justin Derrick]

I should have mentioned that it will likely affect performance, but it should be minor as the DB2 optimizer on LUW is very, very good (and it's probably even better in z/OS).

-JD.

[scott.walsh]

Funny, just saw one of these last week.  Coming from an odwek server interface.  Just a hickup.  Assuming something was out of sync on the odwek server.  Same Reason 07 too.

ARS0013E E476530 DB Error: {DB2 FOR OS/390}{ODBC DRIVER}{DSN12015}                 
DSNT408I SQLCODE = -804, ERROR:  AN ERROR WAS FOUND IN THE APPLICATION             
PROGRAM            INPUT PARAMETERS FOR THE SQL STATEMENT, REASON 07               
                   DSNT418I SQLSTATE   = 07002 SQLSTATE RETURN CODE               
                            DSNT415I SQLERRP    = DSNXECP SQL PROCEDURE           
DETECTING ERROR                      DSNT416I SQLERRD    = -202  0  0             
1  109840  0 SQL DIAGNOSTIC INFORMATION       DSNT416I SQLERRD    = X'             
FFFFFF36'  X'00000000'  X'00000000'  X'FFFFFFFF'                  X'               
0001AD10'  X'00000000' SQL DIAGNOSTIC INFORMATION                                 
ERRLOC=5:10:2 -- SQLSTATE=07002, SQLCODE=-804, File=arsdoc.c, Line=3442           




DSNT408I SQLCODE = -804, ERROR:  AN ERROR WAS FOUND IN THE APPLICATION                 
-------------------------------------------- V=IBM P=DB2 ERROR CODES R=V12 I=-804 D=M --
********************* Text Below Copyright (c) 2024, IBM *********************         
 -804                                                                                   
 -804 AN ERROR WAS FOUND IN THE APPLICATION PROGRAM INPUT PARAMETERS FOR THE           
 SQL STATEMENT, REASON reason                                                           
                                                                                       
 Explanation                                                                           
 The call parameter list or the SQLDA is invalid.                                       
    o The call parameter list, which is created by the precompiler, might be           
      invalid if the application programmer has modified the output of the             
      precompiler, used a variable name beginning with 'SQL' in the                     
      application program, or overwritten the call parameter list in some               
      other way.                                                                       
    o The SQLDA, which is created by the application program, has an invalid           
      data type or data length.                                                         
    o The value of SQLDABC is not consistent with the value of SQLD.                   
                                                                                       
 The following is the list of reason codes:                                             
      01                                                                               
          Open issued for non-cursor.                                                   
                                                                                       
      02                             


                                                   
  07                                               
      SQLDA length is invalid.