DB2 FOR LUW / DB2FORLUW / A50 - DB2

This APAR is to change the APPLICATION_ID built in function from 
non-theadsafe to threadsafe.  This will allow simultaneous 
executions of APPLICATION_ID to run as multiple threads within a 
single db2fmp process rather than a separate db2fmp process per 
call. 
 
Without this APAR fix, a system may experience a high number of 
db2fmp processes. 
 
To identify if APPLICATION_ID is the function in question 
causing the high number of db2fmp processes, first run the 
command: 
db2pd -fmpexechistory 
 
Then look at the output to identify which routine id is 
displayed most often. 
 
Then run a query such as this which assumes routine id 65681 is 
the one that showed up often in the db2pd output. 
select routinename from sysibm.sysroutines where routine_id = 
65681 
 
If the routine name is APPLICATION_ID then the application is 
calling this function many times. 
 
In order to have the APPLICATION_ID changed to threadsafe after 
applying the Fixpack that contains this APAR, please run 
db2updv95 to update the database to the newest functions.

**************************************************************** 
* USERS AFFECTED:                                              * 
* ALL                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 10.5 Fixpack 7                                * 
****************************************************************

To a avoid a high number of persistent db2fmp processes on the 
system in the event there is a spike of db2fmp processes because 
of many simultaneous calls to APPLICATION_ID, the FENCED_POOL 
parameter can be tuned to a lower value.  This will control the 
number of db2fmp processes that will remain in the event of a 
spike in calls. 
 
db2 update dbm cfg using fenced_pool <number>

First fixed in DB2 10.5 Fixpack 7

not known / see Local fix

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

25.06.2015
20.01.2016
20.01.2016