因為要實現CICS的負載均衡（配置CTG/CICS Transaction Gateway工作負載管理器將在后續BLOG中介紹），當一臺服務器A的CICS Server宕掉后，CTG自動調用另一臺服務器B的CICS Server，但是因為環境的差異，在A上編譯好的可執行程序復制到B，CICS調用時報錯，需要在B上重新編譯才行。

問題出現了：當A的CICS宕掉后，CICS客戶端自動調用B的CICS，這時CICS調用訪問DB2的應用程序，報SQL0818N錯誤，重新編譯B上的應用程序（包括db2 prep和cicstcl），不再報錯，但此時將A上的CICS恢復后，當客戶端重新調用A時，A又報SQL0818N。

在網上找到一篇文章《[Share]DB2返回SQLCODE -818 錯誤》(http://blog.csdn.net/caoxicao/archive/2006/11/15/1386165.aspx)，描述的情況是相同的，但是沒有給出解決方法。

這個錯誤的原因是，A和B訪問同一個DB2數據庫，在預編譯SQC文件時（db2 prep xxx.sqc），除了產生.c文件外，還產生一個package存放到DB2數據庫中（syscat.packages表），.c文件和package有一個相同的時間戳，用.c文件編譯連接生成的可執行程序繼承了.c文件的時間戳，也就是說，可執行程序和package的時間戳也是相同的。

當可執行程序訪問DB2時，DB2會檢查兩個時間戳是否一致，如果不一致，就報錯：“SQL0818N A timestamp conflict occurred.”

所以在B上預編譯了程序，更新了package的時間戳，A上的程序因為時間戳和package的不一致，就不能再運行。

通過在IBM官網DB2 Information Center搜索關鍵字：timestamp conflict，找到一篇文章《Precompiler-Generated Timestamps》(http://publib.boulder.ibm.com/infocenter/db2luw/v8//topic/com.ibm.db2.udb.doc/ad/c0005565.htm)，文章中提供了解決方法。

在db2 prep xxx.sqc時加上version參數。例如，在A上用db2 prep xxx.sqc version 1預編譯，在B上用db2 prep xxx.sqc version 2預編譯。用db2 "select substr(pkgname,1,8),pkgversion,EXPLICIT_BIND_TIME from syscat.packages where pkgname ='xxx'"查詢，發現有兩條package記錄，pkgversion分別是1和2。

這樣，當預編譯B上的程序時，將不會影響到A上程序的package時間戳，就不會使A上的程序運行時報錯。同樣，預編譯A上的程序時，也不會影響到B上的程序執行。

還有一種方法，就是只在一個地方預編譯SQC文件：把A上預編譯產生的.c文件拿到B上編譯連接（在B上不執行db2 prep，也就不更新package的timestamp），產生的程序也擁有和A上的程序以及數據庫里package相同的時間戳，執行時也不會報錯。

附：db2 prep xxx.sqc，默認產生或者更新（如果package已存在）package（pkgname='xxx'，長度為8，超過截取前8位），如果指定bindfile參數，即db2 prep xxx.sqc bindfile，則不產生或者更新package，而是產生xxx.bnd文件，在db2 bind xxx.bnd時產生或者更新package。