PM84045: ABEND0C4 RC00000038 AT DSNXRINS OFFSET05C2 FOR A QUERY INCLUDES A UDF INVOKED BY A MIGRATED CALLER PACKAGE BOUND IN DB2 V9

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• ABEND0C4 RC00000038 AT DSNXRINS OFFSET05C2 FOR A QUERY INCLUDES
  A UDF INVOKED BY A MIGRATED CALLER PACKAGE BOUND IN DB2 V9
  

Local fix

• REBIND THE MIGRATED CALLER APPLICATION PACKAGE IN DB2 10 FOR
  Z/OS
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All DB2 10 for z/OS users of packages bound  *
  *                 on DB2 for z/OS v8 or DB2 9 for z/OS that    *
  *                 contain queries accessing Table UDFs.        *
  ****************************************************************
  * PROBLEM DESCRIPTION: An ABEND0C4 rc38 can occur at location  *
  *                      DSNXRINS +05C2 or OFFSET05C2 when       *
  *                      executing a package that was bound on   *
  *                      DB2 v8 or DB2 v9 that contains a query  *
  *                      that accesses a Table UDF (User Defined *
  *                      Function).  The failure can occur even  *
  *                      with apar PM54525 applied.              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  An ABEND0C4 rc38 can occur at location DSNXRINS +05C2 when
  executing a package that was bound on DB2 v8 or DB2 v9 that
  contains a query that accesses a Table UDF (User Defined
  Function). The failure can occur even with apar PM54525
  applied.
  
  The problem occurs during runtime or at execution time when DB2
  doesn't take the proper code path for a package that was bound
  on DB2 v8 or DB2 v9 that contains a query that accesses a Table
  UDF.  Because an improper code path is taken, an incorrect
  module is accessed which leads to the ABEND0C4 during
  processing.
  
  In the reported case, the failure occurred when executing a
  package that originated on a DB2 v9 subsystem.
  
  The following simple example illustrates how this failure can
  occur.
  
  Given:
  A DB2 9 subsystem in COEXISTENCE mode with a DB2 10 subsystem.
  
  Step 1. Create a Table T1 on the DB2 v9 subsystem as follows.
  
    CREATE TABLE T1 (ID INT, ID2 INT);
  
    INSERT INTO T1 VALUES(1, 11);
    INSERT INTO T1 VALUES(1, 12);
    INSERT INTO T1 VALUES(1, 13);
    INSERT INTO T1 VALUES(1, 14);
    INSERT INTO T1 VALUES(2, 21);
    INSERT INTO T1 VALUES(2, 22);
    INSERT INTO T1 VALUES(2, 23);
    INSERT INTO T1 VALUES(2, 24);
  
  
  Step 2.  Create an external Table UDF whose body contains a
  dynamic prepare for an SQL statement which performs a fetch into
  some host variables.  Create this UDF on the DB2 v9 subsystem.
  
    CREATE FUNCTION SCE92101.UFE921X4(P1 INT)
      RETURNS TABLE(C1 INT,
                    C2 INT)
      PARAMETER CCSID EBCDIC
      PARAMETER STYLE DB2SQL
      SPECIFIC UDFE9X4
      LANGUAGE C
      FENCED
      WLM ENVIRONMENT WLMENV3
      COLLID          PKE921X4
      EXTERNAL NAME   PKE921X4
      PROGRAM TYPE MAIN;
      ...
  
   SELECT ID, ID2 FROM T1 WHERE ID = ?;
  
  
  Step 3. Prepare and bind an application which invokes this
  Table UDF as follows on the DB2 v9 subsystem.
  
    EXEC SQL DECLARE CS1 CURSOR FOR
       SELECT * FROM TABLE (SCE92101.UFE921X4(1)) AS TB;
  
  
  Step 4. Execute the bound package on the DB2 v10 subsystem.
  
  The above abend can occur when DB2 enters the wrong module after
  incorrectly checking the Table UDF package level.
  
  Additionally, please note that it was reported that an incorrect
  result can be returned instead of an abend.
  

Problem conclusion

• The code in DB2 runtime is modified to take the proper code path
  for a DB2 v8 or DB2 v9 bound package that contains queries that
  can access a Table UDF.
  
  Additional Keywords: SQLUDF SQLTUDF SQLMIGRATION
  

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:

  UK93250

Modules/Macros

• DSNXRGPL
  

Fix information

• Fixed component name

  DB2 OS/390 & Z/

• Fixed component ID

  5740XYR00

Applicable component levels

• RA10 PSY UK93250

     UP13/04/25 P F304

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.