DB2 FOR LUW / DB2FORLUW / 980 - DB2

On systems with a high number of licensed CPU cores calling a 
non-SQL routine (stored procedure/user defined 
function) may hang or return SQL1042. 
 
The db2diag.log will also contain messages indicating that the 
call to sqlochsr failed with the error SQLO_NOSEG such as the 
example below.  Note the example was from Windows so on 
Linux/UNIX the CALLED and OSERR parts of the message may differ 
slightly. 
 
2010-01-01-11.00.36.987000-400 I6620F560          LEVEL: Severe 
(OS) 
PID     : 1224                 TID  : 3924        PROC : 
db2fmp64.exe 
INSTANCE: DB2                  NODE : 000 
EDUID   : 3924 
 
FUNCTION: DB2 UDB, SQO Memory Management, sqlocshr, probe:140 
MESSAGE : ZRC=0x850F0005=-2062614523=SQLO_NOSEG 
          "No Storage Available for allocation" 
          DIA8305C Memory allocation failure occurred. 
CALLED  : OS, -, OpenFileMapping 
OSERR   : 2 "The system cannot find the file specified." 
DATA #1 : String, 21 bytes 
Global\DB2SHMDB2_0DBM 
 
On AIX system you might see the following in the db2diag.log: 
 
CPU: total:<double digit value> 
 
and message: 
 
2010-07-20-16.23.40.766844-240 I133669A805        LEVEL: Severe 
( 
PID     : 712742               TID  : 1           PROC : db2fmp 
INSTANCE: webprd               NODE : 000 
EDUID   : 1                    EDUNAME: db2fmp 
FUNCTION: DB2 UDB, SQO Memory Management, sqlocshr, probe:180 
MESSAGE : ZRC=0x850F0005=-2062614523=SQLO_NOSEG 
          "No Storage Available for allocation" 
          DIA8305C Memory allocation failure occurred. 
CALLED  : OS, -, shmat 
OSERR   : EINVAL (22) "Invalid argument" 
DATA #1 : Memory set handle, PD_TYPE_OSS_MEM_SET_HDL, 48 bytes

**************************************************************** 
* USERS AFFECTED:                                              * 
* ALL                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See ERROR DESCRIPTION.                                       * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* This fix should be installed on the server running the       * 
* non-SQL stored procedures.                                   * 
****************************************************************

Workaround for AIX: 
 
 
The "CPU: total: " value equals to all logical CPUs on the 
physical  box, including all LPARs calculated using the value of 
"maximum virtual processors". 
 
Check lparstat -i and change if possible the value of "maximum 
virtual processors" from  hardware management  console (HMC) to 
reduce the value of "CPU: total:" reported in db2diag.log.

Problem was first fixed in v9.8 Fixpack 2.  At minimum this fix 
should be applied to the server.

not known / see Local fix

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

16.03.2010
13.09.2010
13.09.2010

9.8.FP2