PQ25759: SQLSTATES1010 USING SQLROWCOUNT AFTER A CALL TO A STORED PROCEDURE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• SQLSTATES1010 USING SQLROWCOUNT AFTER A CALL TO A STORED
  PROCEDURE
  
  Note: For DB2 Version 5, the equivalent APAR is PQ25240.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: DB2 UDB for OS/390 Open Database             *
  *                 Connectivity (ODBC) users                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: Problems Reported:                      *
  *                      - SQLSTATE S1010 on SQLRowCount after   *
  *                        SQL CALL statement                    *
  *                      - SQLCODE -514 on second SQLExecute     *
  *                      - SQLGetInfo SQL_ACTIVE_TRANSACTIONS    *
  *                        always returns 0                      *
  *                      - pthread_mutex_lock contention         *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Problems Addressed By This APAR
  -------------------------------
  
  (1) SQLSTATE S1010 on SQLRowCount after SQL CALL statement:
  SQLExecute of an SQL CALL statement resulted in a return
  code SQL_SUCCESS_WITH_INFO due to truncated string data.
  This caused internal state information not to be set
  correctly.  The subsequent call to SQLRowCount then
  issued S1010 (Function Sequence Error) when in fact
  a valid sequence had been executed.
  
  (2) SQLCODE -514 SQLSTATE 26501 from DSNXERT2, SQLERRD1 = -304.
  This symptom was encountered in a JDBC application that
  had issued this sequence:
       ResultSet rs = pstmt.executeQuery();
       rs.close();
       rs = pstmt.executeQuery(); << SQLCODE -514
  
  This symptom could also be encountered in an ODBC application
  that issues this sequence:
       SQLExecute( hStmt );
       SQLFreeStmt( hStmt, SQL_CLOSE);
       SQLExecute( hStmt ); << SQLCODE -514
  
  ODBC code is not tracking the prepared state of the SQL
  statement after SQLFreeStmt, and fails to Prepare the statement
  again when the second SQLExecute is issued.
  
  (3) SQLGetInfo with fInfoType == SQL_ACTIVE_TRANSACTIONS always
  returns value 0, but should return the value that is set using
  the MAXCONN ODBC initialization file keyword.
  
  (4) Excessive number of calls to pthread_mutex_lock function in
  ODBC code causes degraded performance in multithreading
  applications due to mutex contention.  'Mutex contention' is
  defined as the case in which POSIX pthreads must wait to acquire
  a mutex which is held by another pthread.
  
  ================================================================
  == Action Information for PQ25759                             ==
  ================================================================
  
  The following action information also appears as ++HOLD(ACT) in
  the PTF for PQ25759:
  
  ***Action for PQ25759:
  
  Database Request Module (DBRM) DSNCLIQR is updated by this PTF.
  Application of this PTF requires a BIND PACKAGE ACTION(REPLACE)
  for DSNCLIQR.  If the BIND is not performed after applying this
  PTF, an SQLCODE -805 can result when running ODBC applications.
  
  To bind the DSNCLIQR package, refer to the sample DB2 ODBC
  bind job DSNTIJCL in the SDSNSAMP dataset for an example of how
  to perform the BIND command.
  

Problem conclusion

• (1) Code was added on SQL CALL statement path to set execution
  state information.
  
  (2) If a cursor has been closed and its prepared statement has
  been destroyed by SQLFreeStmt(SQL_CLOSE), ODBC code will prepare
  the cursor statement when it is referenced again in
  SQLExecute, to avoid the SQLCODE -514.
  
  (3) ODBC code has been changed to properly handle the MAXCONN
  INI file keyword and to return its value using SQLGetInfo.
  
  (4) Mutex locking has been optimized to reduce contention.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UQ30101

Modules/Macros

•    CLICONN  CLICSR   CLIERR   CLIOPT   CLIQRY
  DSN@LIQR DSNAOCLI DSNAOSDK
  

Fix information

• Fixed component name

  DB2 ODBC/JDBC/S

• Fixed component ID

  5740XYR02

Applicable component levels

• R617 PSY UQ30101

     UP99/05/28 P F905

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.