IBM Support

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

Subscribe

You can track all active APARs for this component.

 

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.
    

Problem conclusion

  • fixed in V9.5 Fp4
    

Temporary fix

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

Comments

APAR Information

  • APAR number

    LI73860

  • Reported component name

    DB2 UDE ESE LIN

  • Reported component ID

    5765F4104

  • Reported release

    950

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2008-11-03

  • Closed date

    2009-05-28

  • Last modified date

    2009-05-28

  • 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

  • R950 PSY

       UP

[{"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSEPGG","label":"DB2 for Linux, UNIX and Windows"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"950","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
28 May 2009