LI73859: APPLICATION WITH NO DGTTS, MIGHT BE ABLE TO ACCESS CACHED SQL REFERENCING A DGTT OF A DIFFERENT CONNECTION

DB2 Version 9.1 Fix Pack 7  for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 7a  for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 8  for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 9  for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 10  for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 11  for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 12  for Linux, UNIX and Windows

APAR status

• Closed as program error.

Error description

• Application with no DGTTs, might be able to access cached SQL
  referencing a DGTT of a different connection.
  
  Symptoms:
  a) For the application with no DGTT issuing the statement:
       - if the statement is an insert/update/delete statement,
  then an sqlcode -901 is returned indicating:
  "sqlrl_userTempIUD: tid/fid not found"
       - if the statement is a SELECT statement, then the select
  can succeed
  
  b) if the application with the DGTT drops the usertemp at the
  same time as this access, the instance will panic, with the
  folllowing errors in the db2diag.log:
  
  2008-10-04-01.47.57.968433-240 I514644E513        LEVEL: Severe
  PID     : 24733                TID  : 183034426432PROC :
  db2agent (NYDCTPI1) 0
  INSTANCE: nydctpi1             NODE : 000         DB   :
  NYDCTPI1
  APPHDL  : 0-566                APPID:
  148.86.111.81.14011.09091708483
  AUTHID  : DCTMAC
  FUNCTION: DB2 UDB, data management, sqldDropObj, probe:415
  MESSAGE : TCB fix count != 1 when dropping data object!
  DATA #1 : Hexdump, 8 bytes
  0x0000000756D2BF98 : 0200 0000 0000 0000
  ........
  
  
  In order to be exposed to this bug, the application that has the
  DGTT must have issued the following sequence of steps:
  
  1) prepare a statement referencing the DGTT using a statement
  handle
  2) drop the DGTT
  3) prepare or execute the same statement in 1) using the same
  statement handle
  4) rollback the transaction or the savepoint including the drop
  of the DGTT
  5) prepare or execute the same statement in 1) using the same
  statement handle
  
  workaround:
  - do not issue queries on DGTTs when the DGTT does not exist
  

Local fix

• workaround:
  - do not issue queries on DGTTs when the DGTT does not exist
  

Problem summary

• Application with no DGTTs, might be able to access cached SQL
  referencing a DGTT of a different connection.
  Symptoms:
  a) For the application with no DGTT issuing the statement:
       - if the statement is an insert/update/delete statement,
  then an sqlcode -901 is returned indicating:
  "sqlrl_userTempIUD: tid/fid not found"
       - if the statement is a SELECT statement, then the select
  can succeed
  
  b) if the application with the DGTT drops the usertemp at the
  same time as this access, the instance will panic, with the
  folllowing errors in the db2diag.log:
  
  2008-10-04-01.47.57.968433-240 I514644E513        LEVEL: Severe
  PID     : 24733                TID  : 183034426432PROC :
  db2agent (NYDCTPI1) 0
  INSTANCE: nydctpi1             NODE : 000         DB   :
  NYDCTPI1
  APPHDL  : 0-566                APPID:
  148.86.111.81.14011.09091708483
  AUTHID  : DCTMAC
  FUNCTION: DB2 UDB, data management, sqldDropObj, probe:415
  MESSAGE : TCB fix count != 1 when dropping data object!
  DATA #1 : Hexdump, 8 bytes
  0x0000000756D2BF98 : 0200 0000 0000 0000
  ........
  

Problem conclusion

Temporary fix

• - do not issue queries on DGTTs when the DGTT does not exist
  

Comments

APAR Information

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

  LI73857

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

Fix information

• Fixed component name

  DB2 UDE ESE LIN

• Fixed component ID

  5765F4104

Applicable component levels

• R910 PSY

     UP