PK68554: EXTRA INDEX GETPAGES WITH MRF WHEN MIXING ROWSET CURSOR WITH NON-ROWSET FETCH

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• When a cursor is defined WITH ROWSET POSITIONING and the FETCH
  is a FETCH NEXT (without the ROWSET keyword) every FETCH does a
  RELPAGE/GETPAGE of the current index page.
  
  The problem does not occur when using a ROWSET cursor and FETCH
  NEXT ROWSET.
  
  Note: This problem can occur for any type of application that
  uses the construct described above. It can also show up when
  using ODBC z/OS (via RRS). ODBC uses ROWSET cursors in V9 (or V8
  after PK15288) allowing SQLExtendedFetch() to use the multi-row
  FETCH (MRF) statement (FETCH NEXT ROWSET) when connected to a
  DB2 for z/OS subsystem that supports multi-row FETCH.
  In case the application does not use SQLExtendedFetch(), the
  cursor that is used is still still defined as a ROWSET cursor
  but the fetches will be FETCH NEXT, which makes that have the
  scenario described above.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All DB2 users using multi-row fetch          *
  *                 cursors.                                     *
  ****************************************************************
  * PROBLEM DESCRIPTION: Perform extra index getpages while      *
  *                      fetching next rowset for 1 row with MRF *
  *                      rowset cursor.                          *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  While processing a FETCH NEXT ROWSET FOR 1 ROW with a
  Multi-row fetch rowset cursor, the index page was released
  unnecessarily and cause an extra getpage of the same index
  page later.  The problem occurs because an uninitialized
  variable caused DB2 to release the index page.
  
  For example:
  
     EXEC SQL
        DECLARE CS1 CURSOR WITH ROWSET POSITIONING
           FOR
           SELECT LASTNAME
           FROM DSN8910.EMP WHERE EMPNO > '000001'
  
     EXEC SQL OPEN CS1
  
     EXEC SQL FETCH NEXT  ROWSET FROM CS1 FOR 1 ROWS
              INTO :HV
  

Problem conclusion

• DB2 code was fixed to properly initialize the internal
  variable to ensure the index page is not released
  unnecessarily.
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

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

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

  UK39668 UK39669

Modules/Macros

• DSNICPOS DSNICREL
  

Fix information

• Fixed component name

  DB2 OS/390 & Z/

• Fixed component ID

  5740XYR00

Applicable component levels

• R810 PSY UK39668

     UP08/09/25 P F809

• R910 PSY UK39669

     UP08/09/25 P F809

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.