Base on the following link:
I turn on the the DB2_CAPTURE_LOCKTIMEOUT=ON, and then I check whether I successful change it or not by db2set -all, and I can see that its already turn to ON.
After that, I successfully simulate the locktimeout by follow this link:
https://db2forum.wordpress.com/2011/10/17/new-options-for-analyzing-lock-timeouts-in-db2-9-5/
I successfully get Reason code "68". SQLSTATE=40001.
However, I still cant get any db2locktimeout log at /home/db2inst1/sqllib/db2dump.
I only can see db2diag.log in this path but not the db2locktimeout log.
May I know what is the mistake I make?
As you quoted a V10.5 page, I assume your Db2-server is at least at that version. Always write your Db2-version and fixpack when asking for help.
This deprecated (but still working) variable is only effective for newly compiled SQL statements. This means that if your package-cache already has the SQL statements cached (the ones that you use to recreate the -911 reason code 68) then no file(s) will appear for those SQLs if they are involved in the -911.
If your recreation scenario can work on a development or a test database then you can either flush the dynamic statement cache (do not do this on production), or you can bounce the Db2-instance (which has the side effect of clearing the package cache).
If your recreation scenario uses only static-SQL the either those packages will need to be rebound (do not do this on production), or you can bounce the Db2-instance.
If you can only recreate the issue on production, and flushing or bouncing or rebinding is too invasive on that environment, then the alternate approach of using an event monitor for locking is recommended, although it requires a lot more effort.
To learn more about how Db2 compiles SQL, and how dynamic-SQL statements get stored along with their access-plan in memory (called the package-cache), study the Db2-Knowledge Centre or consult any Db2 reference book.