The reason for a deadlock is created when two applications are each locking data needed by the other, resulting in a situation when neither application can continue execution. So, Application A and B are both locking data that is needed by the other to complete the transaction.
What you can do about it or locate the deadlock details:
1) You could try to commit more often.
2) Use the FOR UPDATE clause when performing a select operation on rows that are intended to be updated. This clause ensures that a U lock is set when a process attempts to read data, and it does not allow row blocking.
The U mode lock is used for intent to update locking. It allows deadlock prevention as it is not compatible with itself. DB2 could acquire a U lock for application 1, when a row is retrieved for a cursor with the FOR UPDATE clause. If application 2 also tries to access the same row using a cursor defined FOR UPDATE, the request for a U lock for the row will force application 2 to wait for the first application to release the lock.
3) To log more information about deadlocks, set the value of the diaglevel database manager configuration parameter to 4. The logged information includes the name of the locked object, the lock mode, and the application that is holding the lock. The current dynamic SQL and XQuery statement or static package name might also be logged.
4) Enable deadlock event monitoring and inspect the detailed output file to see the details of the deadlock that occurred
DB2 9.7 - Lock events for DB2 for Linux, UNIX, and Windows, Part 3: Use the lock event monitor in DB2 9.7 to solve concurrency issues
DB2 8 and 9 - IBM Default deadlock event monitor - United States
Hope this helps...