DB2 FOR LUW / DB2FORLUW / A10 - DB2

The FCM buffer discarded message can be seen in db2diag.log on a 
remote partition. 
 
2013-08-05-01.09.07.477149+480 I16501733A701      LEVEL: Error 
PID     : 2294174              TID  : 1543        PROC : db2sysc 
10 
INSTANCE: db2inst1             NODE : 010 
EDUID   : 1543                 EDUNAME: db2fcmr 10 
FUNCTION: DB2 UDB, fast comm manager, 
sqkfFastCommManager::RouteInboundBuffer, probe:30 
DATA #1 : <preformatted> 
rc = 0x0; buffer addr: 7800000a3a39080 
buffer info: channel ID=478015836, sender node=0, conduit ID=0, 
sequenceNo=4294967295, sessionId=0, priority=0, 
msgFlags=0x30009, 
msgType=1 
app_hdl=0-18506, app_stamp=594176, sourceNode=0, idtype=1, 
idflags=0, bdsCounter=28, nestedCounter=0 
(BDS) subtaskId=33, sendNode=0, intFlags=0x0, bdsFlags=0x2 
(BQS) counter=33, node=0 
 
DB2 has an internal unique counter called app_stamp based off 
epoch time for each incarnation of an app-handle. But due to the 
way DB2 calculates this unique number, it can wrap. Because the 
unique identifier wraps, it caused a problem in the logic of 
our code that ultimately lead to a buffer being discarded, and 
an application being hung. 
 
Note : 
- On DB2 Version 9.7 or higher, EDUNAME is db2pdbc and the 
FUNCTION is 
sqkfFastCommManager::DeliverBufferToTargetChannel,probe:30 
- This issue only applies to the DB2&#65449; partitioned database 
environment. 
- This issue also impacts pureScale instance.

The FCM buffer discarded message can be seen in db2diag.log on a 
remote partition. 
 
2013-08-05-01.09.07.477149+480 I16501733A701      LEVEL: Error 
PID     : 2294174              TID  : 1543        PROC : db2sysc 
10 
INSTANCE: db2inst1             NODE : 010 
EDUID   : 1543                 EDUNAME: db2fcmr 10 
FUNCTION: DB2 UDB, fast comm manager, 
sqkfFastCommManager::RouteInboundBuffer, probe:30 
DATA #1 : <preformatted> 
rc = 0x0; buffer addr: 7800000a3a39080 
buffer info: channel ID=478015836, sender node=0, conduit ID=0, 
sequenceNo=4294967295, sessionId=0, priority=0, 
msgFlags=0x30009, 
msgType=1 
app_hdl=0-18506, app_stamp=594176, sourceNode=0, idtype=1, 
idflags=0, bdsCounter=28, nestedCounter=0 
(BDS) subtaskId=33, sendNode=0, intFlags=0x0, bdsFlags=0x2 
(BQS) counter=33, node=0 
 
DB2 has an internal unique counter called app_stamp based off 
epoch time for each incarnation of an app-handle. But due to the 
way DB2 calculates this unique number, it can wrap. Because the 
unique identifier wraps, it caused a problem in the logic of 
our code that ultimately lead to a buffer being discarded, and 
an application being hung. 
 
Note : 
- On DB2 Version 9.7 or higher, EDUNAME is db2pdbc and the 
FUNCTION is 
sqkfFastCommManager::DeliverBufferToTargetChannel,probe:30 
- This issue only applies to the DB2&#169; partitioned database 
environment. 
- This issue also impacts pureScale instance.

Recycle the db2 instance.

DB2 Version 10.1 Fix Pack 4 for Linux, UNIX, and Windows
 DB2 Version 10.1 Fix Pack 6 for Linux, UNIX, and Windows
 

First fixed in DB2 Version 10.1 Fix Pack 4

not known / see Local fix

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

13.08.2013
22.07.2014
22.07.2014