PQ51846: AN SQLJ APPLICATION, WHICH WAS NOT CUSTOMIZED, ENTERS A LOOP AFTER A CALL TO A STORED PROCEDURE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• If an SQLJ application, which was NOT customized, calls a stored
  procedure, then the application can go into a loop.  The problem
  can be bypassed by customizing the SQLJ application.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All DB2 for OS/390, Version 6, Java JDBC     *
  *                 and SQLJ users.  The DB2 for OS/390          *
  *                 Version 5 equivalent APAR is PQ51845.        *
  *                 The DB2 for OS/390 Version 7 equivalent      *
  *                 APAR is PQ51847.                             *
  ****************************************************************
  * PROBLEM DESCRIPTION: This APAR includes fixes for several    *
  *                      reported defects that are applicable    *
  *                      to all DB2 for OS/390 SQLJ/JDBC         *
  *                      driver users.                           *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  In addition to the problem that this APAR was initially
  opened for, this APAR also fixes several other problems
  that have been reported against the DB2 for OS/390 SQLJ/JDBC
  driver.  See the problem conclusion for a list of defects
  that have been addressed by this APAR.
  
            *** IMPORTANT NOTE BEGIN ***
  This APAR corrects several issues related to SQLJ application
  customization, parsing, and the online-checker processing.
  SQLJ applications that are experiencing any of the
  customization, parsing, or online-checker problems described
  in this APAR will need to be recustomized and the generated
  SQLJ DBRM's will need to be rebound in order to benifit from
  the fixes in this APAR.
  
  If you are using the DB2 for OS/390 SQLJ/JDBC driver with
  the VisualAge for Java, Enterprise Edition for OS/390,
  you must rerun the installVAJDLLs installation script
  after installing this APAR.  You should also verify that your
  customized version of the installVAJDLLs script is current
  with the installVAJDLLs script that is shipped with this
  product.
  
  If you are using the DB2 for OS/390 SQLJ/JDBC driver in an
  environment that requires that dynamic load libraries (DLLs)
  be marked as program controlled or if you have previously
  marked the DB2 SQLJ/JDBC driver DLLs as being program
  controlled, you will need to re-apply the program control
  extended attribute after the application of this APAR.
            *** IMPORTANT NOTE END ***
  

Problem conclusion

•   The following defect fixes are provided in this APAR:
    =====================================================
  - If an SQLJ application calls a stored procedure and
    the calling SQLJ application has NOT been customized,
    then it will go into a loop.  The loop is in the default
    customization code supplied in the reference
    implimentation due to a while statement that calls
    (Callable)Statement.getUpdateCount expecting a "-1".  The
    problem is that our CallableStatement code is not setting
    the updateCount to -1 unless there is a returned ResultSet.
    (d26091)
  - Statement.setQueryTimeout() has been changed to allow a set
    value of 0.  If any non-zero value is passed on the
    setQueryTimeout() call, an SQLException will be thrown.  In
    addition, the Statement.getQueryTimeout() has been changed
    to return the current queryTimeout value.  Previous to these
    changes, any calls to setQueryTimeout() or getQueryTimeout()
    resulted in an SQLException.  (d26394)
  - Program Versioning support for customized SQLJ.  The SQLJ
    program versioning support provides the same functionality
    as the DB2 precompiler "VERSION" option.  See the README
    file for more information about the db2profc -pgmversion
    option. (d22502)
  - Additional diagnostic messages for out of Sections/Cursors
    errors.  The new diagnositic messages will include the SQL
    statement text for all "inuse" Sections/Cursors.  These
    new messages are printed to stderr.  (d26211)
  - SQLJ application received "SQLException: DB2SQLJRTResultSet
    Received Error in Method getIntWrapper => cannot convert
    column type to int."  The SQLJ application was attempting
    to SELECT a DECIMAL(2,0) column into a Java Integer host
    variable.  This conversion should be supported and the
    code has been changed to allow it. (d26832)
  - Fixed two problems with "MaxRows" usage in a customized SQLJ
    program.  The first problem was that the MaxRows value was not
    being reset when a DB2SQLJRTStatement was reused.  The second
    problem was that the state information was not set correctly
    to indicate that the RTResultset was no longer positioned on
    a "valid row" once we reached MaxRows.  Although the
    next/fetch was correctly returning "false" once MaxRows was
    reached, RTResultset.endFetch() was incorrectly returning
    that the cursor was positioned on a "valid" row. (d26940)
  - SQLCODE-180 is received when an input DATE or TIMESTAMP value
    has a year value that is less than 1000. SQLCODE180 (d27323)
  - setObject conversion of an input Boolean to a CHAR type was
    not correct.  This conversion has been changed to convert to
    a character "1" (true) or "0" (false).  (d26577)
  - The DBRM dataset allocation used by SQLJ customization has
    been changed to DISP=SHR, which will allow for concurrent
    DBRM dataset access.  Specifically, it will allow for
    successful DBRM creation in cases where there are other
    DISP=SHR allocations of the DBRM dataset (e.g. Another user
    using ISPF browse) (d27311, d26280)
  - Provide the capability for true STATIC positioned
    update/delete processing for customized SQLJ applications
    when the positioned update/delete is performed within the
    same program as the SELECT.  Prior to this change, SQLJ
    always used a dynamically prepared positioned update/delete.
    This is because an iterator can be passed as an argument to
    another method from another source file (i.e. another SQLJ
    profile and package).  This presented a problem since DB2
    requires that a positioned update/delete MUST be issued from
    the same package as the cursor (iterator).  By always using
    a dynamically prepared positioned update/delete processing,
    the driver could be sure that the positioned update/delete
    was in the same package as the cursor.  However, performance
    can be improved for SQLJ applications where the positioned
    update/delete is issued from the same package as the cursor.
    For these SQLJ programs, true STATIC execution of positioned
    update/delete is now possible.  See the SQLJ/JDBC README file
    for more information on how to enable this support. (d25714)
  - A BIND of a customized SQLJ application which includes a host
    variable type of sqlj.runtime.AsciiStream will fail with
    an ABEND04E RC00E70005 in DSNXODTR.  The SQLJ customization
    is not mapping the sqlj.runtime.AsciiStream to the correct
    SQLTYPE in the DBRM. (d27191)
  - SQLJ online checking of an SQLJ application which includes
    a host variable type of sqlj.runtime.AsciiStream or
    sqlj.runtime.BinaryStream results in message:
     " DB2/OS390  SQL ONLINE CHECKER   ->INFORMATIVE<-
      Validity checking bypassed: unknown Java or DB2 type"
    The SQLJ online checker was not supporting these two
    host variable types correctly.  The online checker code
    has been changed to correctly handle these two SQLJ host
    variable types. (d27630)
  - Corrected the tracking of SQLJ default ConnectionContext
    processing under CICS. (d25214)
  - Added code to prevent an SQLJ application from using a
    ConnectionContext which had been previously closed by the
    application.  (d26512)
  - JDBC ResultSet.getObject for a DB2 SMALLINT column was
    incorrectly returning a java.lang.Integer object instead
    of the expected java.lang.Short object.  This has been
    corrected.  (d26853)
  - SQLJ runtime logic changed to exploit partial online checker
    provided information.  Previous logic would not use the
    online checker information for a statement unless it was
    complete. (d26866)
  - SQLJ online checker was not correctly handling single
    character table, qualifier, or column names (e.g. X.ID,
    ABC.X).
    This would result in an online checker warning message, such
    as:
        DB2/OS390  SQL ONLINE CHECKER   ->WARNING<-
       Validity checking failed: database catalog error
       Invalid table spec(s):
       Table spec <X> (DBT4.null.null) is invalid
    The SQLJ online checker has been change to correctly handle
    single character names.  (d27245)
  - DatabaseMetaData.getSchemas() was returning the incorrect
    results.  It was returning all of the distinct GRANTEEs from
    SYSIBM.SYSUSERAUTH.  It has been corrected to now return all
    distinct CREATORs from both SYSIBM.SYSTABLES and
    SYSIBM.SYSSYNONYMS.  (d27435)
  - SQLJ parser was not identifing the correct output column
    names for certain SELECT statments that include sub-SELECTs.
    One external symptom of this was that the SQLJ customization
    with online checking received java.lang.NullPointerException
    in ...DB2SQLJColumnsCatalog.get3PartName.  (d27192)
  - SQLJ parser enhancement to correctly parse a DB2 V7 UPDATE
    SQL statement syntax like:
      UPDATE tab1 SET (COL1, COL2, ...) = (:h1, :h2, ...)
    Previously, the SQLJ parser would only accept an UPDATE
    SQL statement syntax like:
      UPDATE tab1 SET COL1=:h1, COL2=:h2 ...
    (d27493)
  

Temporary fix

Comments

APAR Information

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

  PQ51845

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

  UQ59528

Modules/Macros

•    DSNAJCS0 DSNAJRME DSNAQCS1 DSNAQCS2 DSNAQLD0
  DSNAQLD1 DSNAQLD5 DSNAQLD6 DSNAQLD7 DSNAQLD8 DSNAQLD9
  

Fix information

• Fixed component name

  DB2 ODBC/JDBC/S

• Fixed component ID

  5740XYR02

Applicable component levels

• R612 PSY UQ59528

     UP01/11/13 P F111

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.