因為要實現(xiàn)CICS的負(fù)載均衡（配置CTG/CICS Transaction Gateway工作負(fù)載管理器將在后續(xù)BLOG中介紹），當(dāng)一臺服務(wù)器A的CICS Server宕掉后，CTG自動調(diào)用另一臺服務(wù)器B的CICS Server，但是因為環(huán)境的差異，在A上編譯好的可執(zhí)行程序復(fù)制到B，CICS調(diào)用時報錯，需要在B上重新編譯才行。
問題出現(xiàn)了：當(dāng)A的CICS宕掉后，CICS客戶端自動調(diào)用B的CICS，這時CICS調(diào)用訪問DB2的應(yīng)用程序，報SQL0818N錯誤，重新編譯B上的應(yīng)用程序（包括db2 prep和cicstcl），不再報錯，但此時將A上的CICS恢復(fù)后，當(dāng)客戶端重新調(diào)用A時，A又報SQL0818N。
在網(wǎng)上找到一篇文章《
[Share]DB2返回SQLCODE -818 錯誤》(http://blog.csdn.net/caoxicao/archive/2006/11/15/1386165.aspx)，描述的情況是相同的，但是沒有給出解決方法。
這個錯誤的原因是，A
和B訪問同一個DB2數(shù)據(jù)庫，在預(yù)編譯SQC文件時（db2 prep xxx.sqc），除了產(chǎn)生.c文件外，還產(chǎn)生一個package存放到DB2數(shù)據(jù)庫中（syscat.packages表），.c文件和package有一個相同的時間戳，用.c文件編譯連接生成的可執(zhí)行程序繼承了.c文件的時間戳，也就是說，可執(zhí)行程序和package的時間戳也是相同的。
當(dāng)可執(zhí)行程序訪問DB2時，DB2會檢查兩個時間戳是否一致，如果不一致，就報錯：“SQL0818N A timestamp conflict occurred.”
所以在B上預(yù)編譯了程序，更新了package的時間戳，A上的程序因為時間戳和package的不一致，就不能再運行。通過在IBM官網(wǎng)
DB2 Information Center搜索關(guān)鍵字：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參數(shù)。例如，在A上用db2 prep xxx.sqc version 1預(yù)編譯，在B上用db2 prep xxx.sqc version 2預(yù)編譯。用db2 "select substr(pkgname,1,8),pkgversion,EXPLICIT_BIND_TIME from syscat.packages where pkgname ='xxx'"查詢，發(fā)現(xiàn)有兩條package記錄，pkgversion分別是1和2。
這樣，當(dāng)預(yù)編譯B上的程序時，將不會影響到A上程序的package時間戳，就不會使A上的程序運行時報錯。同樣，預(yù)編譯A上的程序時，也不會影響到B上的程序執(zhí)行。
還有一種方法，就是只在一個地方預(yù)編譯SQC文件：把A上預(yù)編譯產(chǎn)生的.c文件拿到B上編譯連接（在B上不執(zhí)行db2 prep，也就不更新package的timestamp），產(chǎn)生的程序也擁有和A上的程序以及數(shù)據(jù)庫里package相同的時間戳，執(zhí)行時也不會報錯。
附：db2 prep xxx.sqc，默認(rèn)產(chǎn)生或者更新（如果package已存在）package（pkgname='xxx'，長度為8，超過截取前8位），如果指定bindfile參數(shù)，即db2 prep xxx.sqc bindfile，則不產(chǎn)生或者更新package，而是產(chǎn)生xxx.bnd文件，在db2 bind xxx.bnd時產(chǎn)生或者更新package。