分类：
2010-04-19 14:16:10
|
因为要实现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数据库，在时（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官网搜索关键字：timestamp conflict，找到一篇文章《》()，文章中提供了解决方法。 在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。 |
2009 年 4 月 30 日起不再支持 DB2 通用数据库版本 8。请访问这里以获取更多详细信息：
When generating a package or a bind file, the precompiler generates a timestamp. The timestamp is stored in the bind file or package and in the modified source file. The timestamp is also known as the consistency token.
When an application is precompiled with binding enabled, the package and modified source file are generated with timestamps that match. If multiple versions of a package exist (by using the PRECOMPILE VERSION option), each version will have with it an associated timestamp. When the application is run, the package name, creator and timestamp are sent to the database manager, which checks for a package whose name, creator and timestamp match that sent by the application. If such a match does not exist, one of the two following SQL error codes is returned to the application:
Remember that when you bind an application to a database, the first eight characters of the application name are used as the package name unless you override the default by using the PACKAGE USING option on the PREP command. As well the version ID will be "" (an empty string) unless it is specified by the VERSION option of the PREP command. This means that if you precompile and bind two programs using the same name without changing the version ID, the second package will replace the package of the first. When you run the first program, you will get a timestamp or a package not found error because the timestamp for the modified source file no longer matches that of the package in the database. The package not found error can also result from the use of the ACTION REPLACE REPLVER precompile or bind option as in the following example:
The second precompile and bind generates a package SCHEMA1.PKG that has a VERSION of VER2, and the specification of ACTION REPLACE REPLVER VER1 removes the SCHEMA1.PKG package that had a VERSION of VER1.
An attempt to run the first application will result in a package mismatch and will fail.
A similar symptom will occur in the following example:
At this point it is possible to run both applications A1 and A2, which will execute from packages SCHEMA1.PKG versions VER1 and VER2 respectively. If, for example, the first package is dropped (using the DROP PACKAGE SCHEMA1.PKG VERSION VER1 SQL statement), an attempt to run the application A1 will fail with a package not found error.
When a source file is precompiled but a respective package is not created, a bind file and modified source file are generated with matching timestamps. To run the application, the bind file is bound in a separate BIND step to create a package and the modified source file is compiled and linked. For an application that requires multiple source modules, the binding process must be done for each bind file.
In this deferred binding scenario, the application and package timestamps match because the bind file contains the same timestamp as the one that was stored in the modified source file during precompilation.
This topic can be found in: Application Development Guide: Programming Client Applications.
Binding is the process that creates the package the database manager needs to access the database when the application is executed. Binding can be done implicitly by specifying the PACKAGE option during precompilation, or explicitly by using the BIND command against the bind file created during precompilation.
A typical example of using the BIND command follows. To bind a bind file named filename.bnd to the database, you can issue the following command:
DB2(R) BIND filename.bnd
One package is created for each separately precompiled source code module. If an application has five source files, of which three require precompilation, three packages or bind files are created. By default, each package is given a name that is the same as the name of the source module from which the .bnd file originated, but truncated to 8 characters. To explicitly specify a different package name, you must use the PACKAGE USING option on the PREP command. The version of a package is given by the VERSION precompile option and defaults to the empty string. If the name and schema of this newly created package is the same as a package that currently exists in the target database, but the version identifier differs, a new package is created and the previous package still remains. However if a package exists that matches the name, schema and the version of the package being bound, then that package is dropped and replaced with the new package being bound (specifying ACTION ADD on the bind would prevent that and an error (SQL0719) would be returned instead).
This topic can be found in: Application Development Guide: Programming Client Applications.
