DB2 Enterprise Server Edition v9.5 and higher is only supported in Test and Development mode on 32-bit Linux systems.

A DB2 Enterprise Server Edition permanent license may only be applied on a 64-bit Linux system.

Here are your options: 

• Upgrade the OS to 64-bit Linux and then install Enterprise Server Edition and license.
  
• Purchase another DB2 edition such as DB2 Workgroup Server Edition or DB2 Express Edition. You will need to also obtain and apply the corresponding permanent license.
  
• Purchase DB2 Developer's Edition for 32-bit Linux. The Developer's Edition license certificate (db2dede.lic) can be applied on top of a Enterprise Server Edition install without any problems.

This is caused when a previous installation of TWS was made and it created the default database, TWS.

If you are attempting a reinstallation using the same database name then you should perform the following :-

1. db2 catalog database tws 
2. db2 drop database tws

There is a delay being experienced when executing this command.

A DB2 FORCE APPLICATION command is an interrupt request.

When an agent executes a force, it will set a force flag for the application that it will force and depending on what the coordinator agent is doing, it will react accordingly by either waiting or sending him an interrupt.

In some cases, we will be in a wait mode. This is due to a encountering a higher priority.

When an interrupt is provided, each interrupt has priorities. The general rule of thumb DB2 will only interrupt the target if the target is working on a lower priority.

For example: If an application is in the middle of a rollback and if the user executes a DB2 FORCE APPLICATION command to force it, the database can go into a inconsistent state and therefore, we do not want that to happen. So DB2 will not interrupt the rollback. This control is implemented by the interrupt priority

In this example, just prior to the rollback, the priority will be increased so a lower priority agent in this case the force application will not interrupt him. Also, the force operation is an asynchronous operation. So if the application is in rollback processing, the agent doing the force will only mark the force flag of the application, but will not interrupt the application immediately. After the coordinator agent finishes the rollback, DB2 restores to the lower interrupt level (likely back to 0), and on various places in the code path, the agent checks for interrupt or force, so at this time, DB2 will notice the force and then react to it.

In conclusion, the delay is due to DB2 evaluating priorities prior to executing.

procstack output may show something like below:

0x0900000000251e80 semop(??, ??, ??) + 0xc0 
0x090000001535c9d4 semop@glue11(??, ??, ??) + 0x78 
0x090000001535c85c sqloSSemP__fdpr_3(??, ??, ??, ??) + 0x24 
0x09000000152981b0 sqlccipcrecv(SQLCC_COMHANDLE_T*,SQLCC_COND_T*)(??, ??) + 0xd8 
0x0900000014f579e0 sqlccrecv__fdpr_1(0x700000040000370, 
0x780000007078780, 0xf0000000f000, 0x1, 0x9000000188bcc38, 
0x8d0000000000008d, 0x0, 0x0) + 0x370 
0x0900000015a931b4sqljsDrdaAsNonCoordSPDrive(db2UCconHandle*,sqlerFmpCommInfo*)(??,
??) + 0x1b0

Some sub-agents still remain in database. These can't be forced. This is a current designed behavior of DB2 V9.5 and DB2 V9.7.

Note : DB2 V10.1 has design enhancements which will allow to force such sub-agents using the command.

Either of the following can be used to force the hanging application.

1) Recycle the instance. i.e Issue db2stop and db2start. Incase, recycling the instance is not possible then,

2) Terminate the active FMP processes which will wake up sub-agents.

For Example : Issue db2pd -fmp to find the active FMP processes. You can see output as shown below:

db2pd -fmp shows:

Database Partition 203 -- Active -- Up 3 days 23:55:01 -- Date 2012-09-27-11.34.33.831054

FMP:
Pool Size: 0
Max Pool Size: 200
Keep FMP: YES
Initialized: YES
Trusted Path: /db2home/db2inst1/sqllib/function/unfenced
Fenced User: bifenc
Shared Memory: 0x0780000000290420
IPC Pool: 0x0780000000290480

FMP Process:
Address FmpPid Bit Flags ActiveThrd PooledThrd ForcedThrd Active IPCList
0x07800000077BD000 38732016 64 0x00000002 2 1 0 Yes 0x0780000006FD1600

Active Threads:
Address FmpPid EduPid ThreadId
0x0780000006D3FDC0 38732016 13369 1029
0x0780000006FD0A80 38732016 20027 1286

Pooled Threads:
Address FmpPid ThreadId
0x07800000077BDA80 38732016 772

Forced Threads:
Address FmpPid ThreadId
No forced threads.

When computer name is changed the global registry entries for groups DB2ADMNS and DB2USERS remain unchanged and are not updated, (호스트 이름이 변경되었거나 영문이 아닌 경우에도 발생할 수 있다)

The only way to diagnose this issue is to take a DB2 trace.

The trace will show that the we fail to get the SID for group <old computer name>\DB2USERS

Update the global registry entries with the new name for groups DB2ADMNS and DB2USERS

db2extsec -a <new computer name>\DB2ADMNS -u <new computer name>\DB2USERS

This is a mandatory requirement after a computer name change

Console based installation is not supported by Infosphere Federation Server installer.

The installer supports silent install and GUI mode.

GUI mode requires xWINDOWS. 
GUI command execution:
./iisetup

The silent install mode requires a response file. A sample response file is found in following directory and can be modified to reflect customer environment: 
<Installer Media root>/samples 
Silent installer command execution:
./iisetup -options responsefile.rsp -silent

ハードウェア障害や DB2 自身の障害などにより DB2 のインスタンスが異常終了し、トランザクションが続行できなくなることがあります。
インスタンスが異常終了すると、UNIX/Linux 環境の場合は db2sysc をはじめとする各 DB2 エンジン・プロセス、Windows 環境の場合は db2syscs.exe プロセスが終了します。

例えば、トランザクションがコミットされる前にこのような障害が発生すると、データベース内のデータが矛盾した、または使用不能な状態のままになっている可能性があります。このままではトランザクションの継続ができないため、クラッシュ・リカバリーによってデータベースを整合性があり使用可能な状態に戻す必要があります。

インスタンスが異常終了する主な原因は以下のようなケースが考えられます。

• db2agent や db2pclnr などのスレッド (プロセス) が不正なアドレスをアクセス (SEGV, AV) するなどにより異常終了し、データの整合性を保つために、DB2 自身がインスタンスを強制終了
• db2agent や db2pclnr などのスレッド (プロセス) が DB 破損などクリティカルなエラーにより続行不可能と判断し abort() によってインスタンスを強制終了
• なんらかの原因で DB2 エンジン・プロセスが SIGKILL で強制的に kill され、その結果インスタンス全体が終了

データベースを矛盾したまたは使用不能な状態から回復するために以下の手順を実施してください。

Unix/Linux 環境ではインスタンス・オーナーとしてログインして実行してください。
Windows 環境では Administrator としてログオンし、 DB2 コマンド・ウィンドウから実行してください。

1. インスタンスを再起動します。
   
   db2start
   
2. 障害発生時に未完了になっている作業単位があった場合には、データベースを整合性があり使用可能な状態に戻すためにクラッシュ・リカバリーが必要になります。
   自動再始動 (AUTORESTART) データベース構成パラメーターの値によって対応方法が異なるため、下記コマンドで設定を確認します。
   
   db2 get db cfg for <dbname>
   
   自動再始動有効         (AUTORESTART) = on
   
   
3. 上記パラメーターの値により、データベースの異常終了後、アプリケーションがデータベースに接続するときにデータベース・マネージャーが自動的にデータベース再始動ユーティリティーを呼び出すかどうかが決まります。
   
   1. ON (デフォルト値) に設定している場合：
      データベース・マネージャーによって自動的にクラッシュ・リカバリーが実行されます。
   2. OFFに設定している場合：
      自動再始動は動作しません。クラッシュ・リカバリーが実行される必要がある (再始動される必要がある) データベースに接続を試みたアプリケーションは、SQL1015N エラーを受け取ることになります。この場合は、そのアプリケーションで RESTART DATABASE コマンドを発行し、データベースを再始動する必要があります。
      
      db2 restart database <dbname>
      
4. クラッシュ・リカバリーが正常に完了すると db2diag.log に以下のような ADM1531E メッセージが記録されます。

MESSAGE : ADM1531E Crash recovery has completed successfully.

1. インスタンスを強制終了します。
   1. Enterprise Server Edition の場合、以下のコマンドでインスタンスを強制終了します。
      db2_kill
      
   2. Enterprise Server Edition 以外の場合 (db2_kill コマンドが存在しない場合)、以下のコマンドでインスタンスを強制終了します。
      db2nkill 0
      
2. 不正な IPC リソースを解放します。
   1. IPC リソースを解放します。
      ipclean
      
   2. IPC リソースが残っているか確認します。
      ipcs -a | grep <インスタンス・オーナー名>
      
   3. IPC リソースが残っている場合には、以下コマンドで除去してください。
      ipcrm -q <msgid> (メッセージキューの場合。ipcs で先頭がqのもの)　
      ipcrm -m <shmid> (共有メモリーの場合。ipcs で先頭がmのもの)
      ipcrm -s <semid> (セマフォーの場合。ipcs で先頭がsのもの)
      
      ※ ipcs の出力結果を確認し、ipcrm コマンドではそれぞれメッセージキュー、共有メモリー、セマフォーの ID を指定してください。
      
3. インスタンスを起動します。
   db2start

1. インスタンスを強制終了します。
   1. Enterprise Server Edition の場合、以下のコマンドでインスタンスを強制終了します。
      db2_kill
      
   2. Enterprise Server Edition 以外の場合 (db2_kill コマンドが存在しない場合)、以下のコマンドでインスタンスを強制終了します。
      db2nkill 0
      
2. 不正な IPC リソースを解放します。
   1. IPC リソースを解放します。
      ipclean
      
   2. IPC リソースが残っているか確認します。
      ipcs -q | grep <インスタンス・オーナー名>
      ipcs -m | grep <インスタンス・オーナー名>
      ipcs -s | grep <インスタンス・オーナー名>
      
   3. IPC リソースが残っている場合には、以下コマンドで除去してください。
      ipcrm -q <msgid> (メッセージキューの場合)　
      ipcrm -m <shmid> (共有メモリーの場合)
      ipcrm -s <semid> (セマフォーの場合)
      
      ※ ipcs の出力結果を確認し、ipcrm コマンドではそれぞれメッセージキュー、共有メモリー、セマフォーの ID を指定してください。
      
3. インスタンスを起動します。
   db2start

1. db2syscs.exe およびその子プロセスを強制終了します。
   1. 単一の DB2 製品と DB2 インスタンスのみの環境
      taskkill /f /im db2syscs.exe /t
      
   2. 複数インスタンスの環境
      1. DB2 インスタンスの PID を確認します。
         tasklist /svc /fi "imagename eq db2syscs.exe"
         
      2. DB2 インスタンスを終了します。
         taskkill /f /pid <DB2 インスタンスの PID> /t
         
         ※ /t オプションを指定しないとシステムを再起動までインスタンスを起動できないことがあります。
         
2. インスタンスを起動します。
   db2start

db2 list utilities show detail

1. 再現シナリオや、問題発生時の処理内容が分かっている場合には下記の情報をご送付ください。
2. • 問題発生の時刻・時間帯
   • 問題発生時の処理内容 (特定の SQL を実行したなど)
   • 再現性の有無
     • 特定の操作により起こった場合は、その操作により再度問題が起こるかどうか
   • 発生頻度
   • 再起動によって回復はしているか
     
3. db2support (db2diag.log ファイル、 db2level や データベース構成情報、 トラップ・ファイル等が含まれます)

• db2level の出力
• db2set -all の出力
• get db cfg の出力
• get dbm cfg の出力
• db2diag.log ファイル
• トラップ・ファイル
  • データベース・マネージャー構成パラメーター DIAGPATH で設定したパスに作成されます。
  • SIGKILL(シグナル#9) 以外を受けた場合は、異常終了時にトラップ・ファイルという形でクラッシュした際の情報が出されます。
  • 通常は、根本原因をキャプチャーするトラップ・ファイルが一つと、その問題が他の DB2 プロセスに及ぼす影響をキャプチャーするトラップ・ファイルがいくつか存在します。
  • トラップ・ファイル名は [プロセス ID (PID).スレッド ID (TID).パーティション番号.trap.bin] となります。
  • Windows 環境の場合はトラップ・ファイルはバイナリー・ファイルのため、フォーマット後、バイナリー・ファイルとともにご送付ください。
    
    実行例：
    188.2916.trap.bin というトラップ・ファイルが DIAGPATH に作成されている場合、以下のようにフォーマットできます。
    
    db2xprt 188.2916.trap.bin 188.2916.trap.bin.txt
    
    db2xprt - トラップ・ファイルのフォーマット 
    

This technote provides some FAQs regarding messages in the db2diag.log in regards to db2fmp processes used to run non-SQL routines such as Java and C.

Scenario #1: Threads in db2fmp process, SQL1042

When the DB2 registry variable DB2_MAX_THREADS_PER_FMP is set you may see the messages below which can be safely ignored. This registry variable was introduced as an enhancement to DB2 via IZ08425. 

In some cases the SQL1042 is a legitimate error so its important to note that in this scenario "Max number of thread in fmp reached; no thread created" is the cause of the SQL1042. The SQL1042 can be safely ignored.

Please note that the SQL1042 is transparent to the application, so no errors will be returned to the application. DB2 automatically starts a new db2fmp process to service the existing or subsequent requests.

2011-01-10-11.31.12.480063-300 I34781A381 LEVEL: Warning 
PID : 1200 TID : 1 PROC : db2fmp (Java) 0
INSTANCE: db2inst1 NODE : 000 
EDUID : 1 EDUNAME: db2fmp (Java) 0 
FUNCTION: DB2 UDB, routine_infrastructure, sqlerMasterThreadListener, 
probe:200 
MESSAGE : Max number of thread in fmp reached; no thread created

2011-01-10-12.10.13.923352-300 I74680A573 LEVEL: Warning 
PID : 1234 TID : 100 PROC : db2sysc 
INSTANCE: db2inst1 NODE : 000 DB : SAMPLE 
APPHDL : 0-33648 APPID: 192.168.1.1.50234.11022217100
AUTHID : DB2INST1 
EDUID : 608 EDUNAME: db2agent (SAMPLE) 0 
FUNCTION: DB2 UDB, routine_infrastructure, sqlerMasterThreadReq, 
probe:89 
MESSAGE : FMP reported it could not create a new thread 
DATA #1 : Hexdump, 4 bytes 
0x000000020210F180 : 0000 0C05 ....

2011-01-10-10.02.25.454418-300 I2221A448          LEVEL: Severe
PID     : 1234                 TID  : 100         PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000         DB   : SAMPLE
APPHDL  : 0-51434              APPID: 10.111.41.13.56427.110218150224
AUTHID  : DB2INST1
EDUID   : 260                  EDUNAME: db2agent (SAMPLE) 0
FUNCTION: DB2 UDB, routine_infrastructure, sqlerGetFmpThread, probe:20
RETCODE : ZRC=0xFFFFFBEE=-1042


Scenario #2: Operating system resource issue, SQL1042

The messages are very similar to Scenario #1 so how do we determine if the SQL1042 is legitimate? Work backwards and look for preceding messages originating from the same PID and TID. 

In the case below we see the source of the error is originating from the operating system (OSERR) and the operating system API which returned the error (pthread_create). pthread_create() is an AIX API indicating that the operating system was unable to create a new thread in the db2fmp process. The root cause is likely an operating system limitation or resource issue when trying to create an additional thread due to the EAGAIN return code.


2011-01-01-13.01.03.345767-240 E287334A401 LEVEL: Severe (OS) 
PID : 2609242 TID : 1 PROC : db2fmp (Java) 0
INSTANCE: db2inst1 NODE : 000 
EDUID : 1 EDUNAME: db2fmp (Java) 0 
FUNCTION: DB2 UDB, oper system services, sqloCreateAppThread, probe:100 
CALLED : OS, -, pthread_create 
OSERR : EAGAIN (11) "Resource temporarily unavailable" 

2011-01-01-13.01.03.426469-240 I287736A455 LEVEL: Severe 
PID : 2609242 TID : 1 PROC : db2fmp (Java) 0
INSTANCE: db2inst1 NODE : 000 
EDUID : 1 EDUNAME: db2fmp (Java) 0 
FUNCTION: DB2 UDB, trace services, sqlt_logerr_data (secondary logging 
func, probe:0 
MESSAGE : Failed to create app thread: 
DATA #1 : Hexdump, 4 bytes 
0x0FFFFFFFFFFFEF60 : 0000 000B ... 

2011-01-01-13.01.03.426684-240 I288192A343 LEVEL: Severe 
PID : 2609242 TID : 1 PROC : db2fmp (Java) 0
INSTANCE: db2inst1 NODE : 000 
EDUID : 1 EDUNAME: db2fmp (Java) 0 
FUNCTION: DB2 UDB, routine_infrastructure, sqlerCreateWorkerThread, 
probe:20 
RETCODE : ZRC=0xFFFFFBEE=-1042 


Scenario #3: SQL1042N returned on AIX platforms using Power7 processors

There is an incompatibility between the IBM JDK bundled with DB2 v9.7 and Power7. For details refer to the link db2setup or db2fmp (Java) abnormally terminated on Power7

Scenario #4: SQL1042N returned due to permission issue 

Ensure the DB2 instance home directory has the permission below, otherwise the db2fmp may not be able to access files located in ~/sqllib/function

/home $ ls -la 
drwxr-xr-x 14 db2inst1 db2admg 4096 Aug 04 10:51 db2inst1/

Check the stored procedure binaries in ~/sqllib/function to ensure they are world readable because the fenced userid is usually not the instance owner.

/home/db2inst1/sqllib/function:
-rw-r--r-- 1 db2fenc fencgrp 875 Jul 29 14:24 DUMMY_JAVASP.class 


Check the permission of ~/sqllib/adm/db2fmp and ~/sqllib/adm/db2fmp32 to ensure the "other" group has privileges to execute these two files.

chmod o+r db2fmp
chmod o+r db2fmp32

After the change you should see:

-r-xr-xr-x 1 db2inst1 db2admg 59384 Jan 1 17:09 db2fmp
-r-xr-xr-x 1 db2inst1 db2admg 74743 Jan 1 17:09 db2fmp32



Scenario #5: Executing long running query 

A remote DB2 client has abnormally terminated when executing a long running query which includes a call to a routine. These messages are informational in nature and can be ignored. However the application should contain some exception handling logic to handle any abnormal terminations. Under the covers DB2 will clean up any non-SQL routines being executed on behalf of the connection. one of the side effects is that the db2diag.log may contain a 0xFFFFFB38 ( SQL1224) 

In the example below the message originating from the db2fmp process about "The database manager is not able to accept new requests..." is misleading. The message is originating from the JDBC (db2jcc.jar) used internally by the DB2 server to execute a Java routine and can be ignored. There is nothing wrong with the DB2 database server.

2011-01-12-12.08.33.158935-300 I6813000A541       LEVEL: Error
PID     : 9644                 TID  : 172         PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000         DB   : SAMPLE
APPHDL  : 0-20965              APPID: 192.168.1.1.33819.110220052256
AUTHID  : DB2INST1
EDUID   : 172                  EDUNAME: db2agent (SAMPLE) 0
FUNCTION: DB2 UDB, common communication, sqlcctcptest, probe:11
MESSAGE : Detected client termination
DATA #1 : Hexdump, 2 bytes
0xFFFFFFFF4B7F3376 : 0036                                       .6 

2011-01-12-12.08.33.170419-300 I6813542A523       LEVEL: Error
PID     : 9644                 TID  : 172         PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000         DB   : SAMPLE
APPHDL  : 0-20965              APPID: 192.168.1.1.33819.110220052256
AUTHID  : DB2INST1
EDUID   : 172                  EDUNAME: db2agent (SAMPLE) 0
FUNCTION: DB2 UDB, common communication, sqlcctest, probe:50
MESSAGE : sqlcctest RC
DATA #1 : Hexdump, 2 bytes
0xFFFFFFFF4B7F346E : 0036  

2011-01-01-12.08.33.170664-300 I6814066A503       LEVEL: Error
PID     : 9644                 TID  : 172         PROC : db2sysc 0
INSTANCE: db2inst11             NODE : 000         DB   : SAMPLE
APPHDL  : 0-20965              APPID: 192.168.1.1.33819.110220052256
AUTHID  : DB2INST1
EDUID   : 172                  EDUNAME: db2agent (SAMPLE) 0
FUNCTION: DB2 UDB, base sys utilities, sqeAgent::AgentBreathingPoint, probe:10
CALLED  : DB2 UDB, common communication, sqlcctest
RETCODE : ZRC=0x00000036=54 

2011-01-01-12.08.33.173237-300 I6814570A507       LEVEL: Error
PID     : 9644                 TID  : 172         PROC : db2sysc 0
INSTANCE: db2inst11             NODE : 000         DB   : SAMPLE
APPHDL  : 0-20965              APPID: 192.168.1.1.33819.110220052256
AUTHID  : DB2INST1
EDUID   : 172                  EDUNAME: db2agent (SAMPLE) 0
FUNCTION: DB2 UDB, routine_infrastructure, sqlerInvokeFencedRoutine, probe:40
DATA #1 : Hex integer, 4 bytes
0x804B006D
DATA #2 : Hex integer, 4 bytes
0xFFFFFB38  /* SQL1224 */ 

2011-01-01-12.08.33.173599-300 E6815078A3474      LEVEL: Severe
PID     : 9644                 TID  : 172         PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000         DB   : SAMPLE
APPHDL  : 0-20965              APPID: 192.168.1.1.33819.110220052256
AUTHID  : DB2INST1
EDUID   : 172                  EDUNAME: db2agent (SAMPLE) 0
FUNCTION: DB2 UDB, routine_infrastructure, sqlerReturnFmpToPool, probe:900
DATA #1 : String, 50 bytes
Marking fmp as unstable, fmp is forced or aborted:
DATA #2 : Boolean, 1 bytes
true
DATA #3 : String, 20 bytes
Fmp entry use count:
DATA #4 : unsigned integer, 4 bytes
1
DATA #5 : String, 8 bytes
Fmp TID:
DATA #6 : Hexdump, 4 bytes
0x000000020079F650 : 0000 0037  /* 0x37 = 55 */
DATA #7 : String, 8 bytes
Fmp row:
DATA #8 : sqlerFmpRow, PD_SQLER_TYPE_FMP_ROW, 496 bytes
 fmpPid: 15781 

When executing Java routines one additional side effect is that the message below will appear in the db2diag.log. This message is misleading because there is nothing wrong with the database manager on the DB2 server. The message originates from the JDBC driver which is local to the DB2 server used to execute Java routines. This message can be safely ignored.

2011-01-01-12.08.33.213727-300 I6840110A1387      LEVEL: Warning
PID     : 15781                TID  : 55          PROC : db2fmp (Java) 0
INSTANCE: db2inst1             NODE : 000
EDUID   : 55                   EDUNAME: db2fmp (Java) 0
FUNCTION: DB2 UDB, BSU Java support, sqlejLogException, probe:10
DATA #1 : String, 962 bytes
com.ibm.db2.jcc.am.DisconnectNonTransientException: [jcc][2055][11259][3.61.86] The database manager is not able to accept new requests, has terminated all requests in progress, 
or has terminated this particular request due to unexpected error conditions detected at the target system. ERRORCODE=-4499, SQLSTATE=58009
    at com.ibm.db2.jcc.am.ed.a(ed.java:321)
    at com.ibm.db2.jcc.t4.ab.T(ab.java:1264) 
...


Scenario #6: SQL1131 or SQL4302

This indicates the non-SQL routine was abnormally terminated. This is usually not a serious error as long as the application is coded to handle these exceptions and the messages do not appear frequently e.g. once a month.

2011-02-02-15.01.23.476662-240 I299008A471 LEVEL: Warning 
PID : 8245982 TID : 1280 PROC : db2fmp (Java) 0
INSTANCE: db2inst1 NODE : 000 
EDUID : 12080 EDUNAME: db2fmp (Java) 0 
FUNCTION: DB2 UDB, trace services, sqlt_logerr_data (secondary logging 
func, probe:0 
MESSAGE : Thread of db2fmp terminated with nonzero rc 
DATA #1 : Hexdump, 4 bytes 
0x000000011E7685EC : FFFF FB95 /* SQL1131 */ ...

2011-02-02-15.01.23.883044-240 I299480A453 LEVEL: Severe 
PID : 8245982 TID : 1280 PROC : db2sysc 0 
INSTANCE: db2inst1 NODE : 000 DB : SAMPLE 
APPHDL : 0-40776 APPID: 192.168.1.10.47637.100712165705 
AUTHID : DB2INST1 
EDUID : 17812 EDUNAME: db2agent (CLNPIS) 0 
FUNCTION: DB2 UDB, routine_infrastructure, sqlerDisassociateWithFmp, 
probe:30 
RETCODE : ZRC=0xFFFFFB95=-1131 


Scenario #7: Marking fmp as unstable

This message is returned when DB2 decides to shut down a db2fmp process and can be part of normal DB2 operations. DB2 automatically picks a new db2fmp or creates a new db2fmp process to execute any subsequent calls to stored procedures or UDFS.

To determine whether this message is more than informational please check for additional db2diag.log entries around the same timestamp which return a ZRC return code, 0xFFFFxxxx return code or an error from the operating system (OSERR). Please use the db2diag tool to decode these return codes. 

This message may also be returned when:

• DBM CFG parameter KEEPFENCED=NO since DB2 would terminate any db2fmp process after a routine has completed execution.
• FORCE APPLICATIONS was issued or if "db2stop force" was called.