| « | 九月 2008 | » | ||||
|---|---|---|---|---|---|---|
| 一 | 二 | 三 | 四 | 五 | 六 | 日 |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | |||||
TXSeries/Cics 6.1
Oracle 10.2
Aix 5.3
使用cicsadd批量增加pd之后,region将出现异常。这时如果启动新的region,将出现如下错误:
# cicscp -v start region vhfsserv StartType=cold ERZ059004I/0107: Starting RPC daemon. ERZ059002I/0101: RPC daemon is already running. ERZ096122I/0264: Processing a 'start region' command ERZ096158I/0264: The region 'vhfsserv' is starting ERZ096111I/0224: Processing a start sfs_server command ERZ096141I/0224: Starting SFS server '/.:/cics/sfs/njffs' Process with pid_1200320 went down with PROCESS LOCK held. Shutdown all processes and restart SARPCD |
1.AIX5.3 ML5 补丁
2.停止cics: 确信所有cics进程和sarpcd进程已停止
3.清除所有cics使用的信号量
ipcs -s |grep cics
ipcrm -s
ipcs -m | grep cics
ipcrm -m
4.解压 TXSeries-cics-6100-aix-testfix2.tar.Z文件用pinstall.sh安装
5.热起sfs,启动region(冷热均可)。
CTG6.0.2
WAS6.0.2.13
AIX 5.3
问题描述:
压力测试时,CTG连接失败,出现了如下错误信息:
[11/19/06 23:56:26:767 CST] 00000293 SystemErr R java.io.IOException: CCL6668E: Initial handshake flow failed. [ERROR_CONNECTION_FAILED] at com.ibm.ctg.client.JavaGatewayInterface.initialFlow(JavaGatewayInterface.java:299)
at com.ibm.ctg.client.TcpJavaGateway.open(TcpJavaGateway.java:276)
at com.ibm.ctg.client.JavaGateway.open(JavaGateway.java:370)
at com.ibm.ctg.client.JavaGateway.<init>(JavaGateway.java:163)
at com.vandagroup.engine.execute.message.SentCICSMessage.send(SentCICSMessage.java:88)
at com.vandagroup.engine.execute.element.ECICSMessageProcess.process(ECICSMessageProcess.java:94)
at com.vandagroup.engine.execute.WFProcess.process(WFProcess.java:251)
at com.vandagroup.engine.execute.WFProcess.process(WFProcess.java:169)
at com.vandagroup.engine.execute.WFExecute.processRequest(WFExecute.java:85)
at com.vandagroup.engine.controller.CameFromSubmit.processRequest(CameFromSubmit.java:44)
at com.vandagroup.engine.controller.BaseEngine.handleRequestInternal(BaseEngine.java:99)
at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:139)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:44)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:717)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:658)
l 增大ctg.ini 中maxconnects和maxthreads 参数后,压力测试可以进行。
l 后来发现是应用程序使用JavaGateWay时只是open和ctg 的连接,但并没有主动的去close此连接,导致资源没有释放。
版本描述
TXSeries/CICS v5.1
CUC 2.0 for Sco unixware
问题描述
CCPC大额支付系统和小额支付系统CICS Server报U4419错误信息并宕机。重启CICS Server后系统恢复正常。
该问题在最先在某CCPC大额支付系统发生,后曾经在另外CCPC小额支付系统出现一次,问题发生频率没有规律。
问题分析
IBM CICS实验室已经重现了此问题,通过搜集相关日志信息并加以分析,此问题已被定位为CICS的一个缺陷。引起问题的根本原因是:两个cicsas同时操作了一个相同的通讯定义和XD定义。用户在CICS客户端配置文件CTG.INI中指定client名字和客户端与CICS服务器。
下面为IBM CICS实验室提供的详细分析记录:
1. 当CICS 客户端在CTG.INI中指定一个客户端名,比如ABCD.
2. 连接CICS 客户端到CICS 域,CICS为此连接(称为A)安装了一个通讯定义(CD),名称为CTG.INI中指定的ABCD,对应也安装了一个XD entry(XD为CICS 内部数据结构,对应CD Entry)。
3. CUC客户端启动了几个CICS 服务器交易。
4. CUC客户端和CICS服务器之间的网络断开。
5. 运行在CICS域中的交易完成后,试图ping CUC客户端,发现网络已断开,ping失败。运行CICS交易的cicsas进程试图卸载CD和XD entry,由于存在其它对应连接A的交易仍在运行,所以无法删除CD entry,报"Entry in Use"错。 cicsas发出清除所有使用相同ABCD entry的运行CICS交易调用 ,然后等待5秒钟,再去清除CD entry。cicsas 会重试12次。12次之后,如果仍然不能删除,将放弃删除CD ENTRY,假设下一次从相同客户端发出连接请求时,会删除此CD Entry。
6. 从同一个客户端又发出连接CICS server的connection B请求,试图安装ABCD entry,发现ABCD entry仍然存在,检查connection A是否存在,发现connection A已经停止,则试图卸载CD Entry ABCD,它成功的删除了对应connection A的CD 入口 ABCD,安装对应connection B的CD Entry ABCD 和一个新的XD Entry。这时,试图卸载对应connection A的CD Entry的cicsas(步骤5)醒过来,以为新的CD Entry还是对应原来的connection A,于是删除了此CD Entry(名为ABCD)。这样,就出现了存在XD Entry,但没有对应的CD Entry,有激活的connection,但没有对应CD Entry的情况。此为一个意外事件。
7. CUC客户端和TXSeries服务器之间的连接又断掉了。
8. 此CUC 客户端重新又启动和CICS服务器之间的连接,称为C连接。这个新的连接C试图安装一个新的CD Entry(ABCD),由于对应connection B的CD Entry已经被删掉,所以连接C安装了一个CD Entry和一个对应的XD Entry。
9. 从连接B提交上来的CICS交易检测到连接B已经中止,试图删除CD Entry和XD Entry,在删除XD Entry时,它删除了步骤8中对应连接C的XD Entry,而它本应该清除步骤6中留下的对应连接B的XD Entry。
10. 负责处理连接C的cicsip线程试图访问对应连接C的XD Entry,却发现此XD Entry已经删除,这直接导致了U4419宕机错误。
IBM实验室建议解决方案
IBM CICS实验室建议在CICS域的environment文件中设置如下环境变量:
CICS_KEEPONDELETINGCONNECTION=1
重新温启CICS region使之生效。
CICS环境变量CICS_KEEPONDELETINGCONNECTION可以起到下面作用:
1. 在详细分析记录步骤5中,可以不再有12次的尝试限制,这确保所以对应连接A的CICS交易在完成后,会把对应连接A的CD Entry删掉。
2. 在详细分析记录步骤6中,安装连接B的cicsas发现如果有同名的CD Entry存在,将放弃安装新的CD Entry,报A42K 反常中止,不会试图删除CD Entry。这两步确保了我们不会再遇到从CUC客户端发起的连接是激活的,但还对应有XD Entry的情况。 这样就去除了引起U4419的根本原因。
总结如下,最基本的问题是2个cicsas试图删除相同的CD Entry,这导致了CD Entry数据结构的不一致。CICS_KEEPONDELETINGCONNECTIONS同步了对CD Entry的删除插入动作,保持了CD Entry和XD Entry的一致性 。
IBM CICS实验室使用此方法,解决了在实验室环境重现的U4419问题。
操作系统:AIX 4.3
中间件:CICS4.2 + PTF9
数据库:DB2 UDB v6.1 + PTF9
2. 故障描述
2007-03-11上午出现了2次cics region 异常down的现象.
分析:通过检查cics console日志,也只能发现由于应用程序出现A158错误,并产生了coredump。接着cics region异常down,但并不能知道是那个应用程序引起。二次的Console日志显示如下:
第一次的日志:
ERZ052004I/0602 03/11/07 09:07:36 ywrun : Dump to 'A1580026.dmp' started. ERZ052013I/0409 03/11/07 09:07:37 ywrun : Dump 0026 - 1 core dump(s) created. ERZ052007I/0604 03/11/07 09:07:37 ywrun : Dump to 'A1580026.dmp' completed. ERZ014016E/0036 03/11/07 09:07:37 ywrun : Transaction 'CPMI', Abend 'A158', at '????'. ERZ057002E/0140 03/11/07 09:07:37 ywrun : CICS internal error: Unsuccessful condition '(tran_TidEqual(ThreadTid, OldTid))' for function 'TasLU_ISyncpoint' on line 968 in file '/cics/PTF9/src/tas/lu/src/taslusyn.c' of module 16 ERZ057005E/0140 03/11/07 09:07:37 ywrun : CICS internal error: Abnormally terminating region with exit code 'U5701' ERZ010003I/0094 03/11/07 09:07:37 ywrun : CICS is performing region abnormal termination in process 'cicsas' ERZ052004I/0602 03/11/07 09:07:37 ywrun : Dump to 'SYSA0027.dmp' started. ERZ052007I/0604 03/11/07 09:07:41 ywrun : Dump to 'SYSA0027.dmp' completed. ERZ010089E/0367 03/11/07 09:07:41 ywrun : Application Server 108 ended unexpectedly ERZ010144I/0375 03/11/07 09:07:41 ywrun : Application server 104 started ERZ010144I/0375 03/11/07 09:07:41 ywrun : Application server 105 started ERZ014016E/0036 03/11/07 09:07:41 ywrun : Transaction 'CPMI', Abend 'A147', at '????'. |
第二的日志:
ERZ052004I/0602 03/11/07 10:13:02 ywrun : Dump to 'A1580001.dmp' started. ERZ052013I/0409 03/11/07 10:13:02 ywrun : Dump 0001 - 1 core dump(s) created. ERZ052007I/0604 03/11/07 10:13:02 ywrun : Dump to 'A1580001.dmp' completed. ERZ014016E/0036 03/11/07 10:13:02 ywrun : Transaction 'CPMI', Abend 'A158', at '????'. ERZ057002E/0140 03/11/07 10:13:02 ywrun : CICS internal error: Unsuccessful condition '(tran_TidEqual(ThreadTid, OldTid))' for function 'TasLU_ISyncpoint' on line 968 in file '/cics/PTF9/src/tas/lu/src/taslusyn.c' of module 16 ERZ057005E/0140 03/11/07 10:13:02 ywrun : CICS internal error: Abnormally terminating region with exit code 'U5701' ERZ010003I/0094 03/11/07 10:13:02 ywrun : CICS is performing region abnormal termination in process 'cicsas' ERZ052004I/0602 03/11/07 10:13:02 ywrun : Dump to 'SYSA0002.dmp' started. ERZ052007I/0604 03/11/07 10:13:04 ywrun : Dump to 'SYSA0002.dmp' completed. ERZ010012I/0194 03/11/07 10:13:04 ywrun : CICS is performing an immediate shutdown of region 'ywrun' |
分析:通过检查应用日志,2次出现故障的时间点,都只出现了交易7118的错误。从这点看当时出现故障的原因应该和7118交易有关系。应用日志都出现了应用日志显示如下:
第一次日志:
03-11 09:07:36| 492|ckn11021 |1102|000000|12|
03-11 09:07:36| 183|main |1102|000000|机构[11070720]操作员[1047]交易[1102]结束|
03-11 09:07:36|1591|midtelegram|7118|111111|读socket出错,从电信读回包头失败!|
第二次日志:
03-11 10:13:01|1591|midtelegram|7118|111111|读socket出错,从电信读回包头失败!|
3.3 分析A158dump文件
使用cicsdfmt –r ywrun A158??????.dmp01命令格式化产生的A158 dmp文件。从2次dump中都能发现如下信息,所以基本定位在7118交易引起的。需要应用人员进一步分析。
Program Control Information:
Buffer Address = 0xa015ce9c
Signature = ERZ15PCI
Previous Level = 0xa015d8dc
Load Address = 0x20604df0
Current Program:
Use Control = 0xa00375bc
Comm Area = 0x2012b338
Length = 32000
Data Length = 32000
Transid for link =
SyncOnReturn = FALSE
Program Name = md71181
Index into cache pointer array = 744
Current version of the program = 1
Value of Resident attribute = No
Program full path name = /var/cics_regions/ywrun/bin/md71181
4.建议
通过上面的分析,下一步需要应用人员对7118交易的应用程序,进行故障分析。
昨天下午接到一个电话,告诉我意外删除了/var/cics_regions/lsrun/目录下的所有文件。
我当场要晕倒!!!
但是问题还是要帮忙解决的。
当时远程的操作人员对cics系统是在很不熟悉。怎么能使系统能尽快恢复使用呢?思考了几秒钟......
如果测试机有环境就简单而直接了。马上开始......
远程支持:
1.登陆开发系统,发现有一个测试region。有点高兴了
2.在开发系统上,执行cicsexport -r lstest -o lstest.exp.成功了。
3.把lstest.exp 文件ftp到生产机上。
4.在生产机上,删除原来的region。
cicscp -v destroy region lsrun
5.在生产机上,执行cicsimport -r lsrun -i lstest.exp -S ,成功了。
6.结合生产环境修改lsrun region database 中的RD,LD,XAD,PD,TD。
7.结合生产环境修改lsrun region目录下的environtment.
8.冷启动lsrun
cicscp -v start region lsrun StartType=cold
9.业务恢复了正常。
用了将近1小时的时间。紧张......
总结:在生产机上操作时,rm命令需要多看几眼,再敲回车!!切记!!!
故障描述:
ctgstart启动的时候出现如下错误:
ccl6525:java.net.bindexception:sockect name is
解决办法:
使用netstat -na |grep 2006,发现端口被占用。
最后重新启动机器,ctg正常启动。
问题描述: |
5/12 17:30左右 大量前台交易不能进行: 但CICS server console日志中没有出现异常,cicsterm—〉CEMT I TA可以运行,并且偶尔有几个交易能做。前台 cics client 状态表现为available,但这时前台的交易不能正常返回。重新启动cics client ,状态则为connecting. |
问题解答: |
1. 使用showProcInfo工具,获取了cics的所进程信息。发现cicsip的进程信息和正常情况相差很远: 正常: Waiting to attach to process 49170 ... Successfully attached to cicsip. warning: Directory containing cicsip could not be determined. Apply 'use' command to initialize source path. Type 'help' for help. reading symbolic information ... stopped in evt._pthread_ksleep [/usr/lib/libpthreads.a] at 0xd00e2d4c ($t4) 0xd00e2d4c (_pthread_ksleep+0x9c) 80410014 lwz r2,0x14(r1) thread state-k wchan state-u k-tid mode held scope function $t1 wait 0xe60b32bc blocked 733945 k no sys _pthread_ksleep $t2 wait 0xe60097bc blocked 38679 k no sys _pthread_ksleep $t3 wait 0x32e7c904 running 91099 k no sys _ptrgl >$t4 run blocked 743665 k no sys _pthread_ksleep $t5 wait 0xe601f1bc blocked 127245 k no sys _pthread_ksleep $t6 wait 0xe6030fbc blocked 200545 k no sys _pthread_ksleep $t7 wait 0xe60310bc blocked 200893 k no sys _pthread_ksleep $t8 wait 0xe60b2ebc blocked 732729 k no sys _pthread_ksleep $t9 wait 0xe60b8fbc blocked 757693 k no sys _pthread_ksleep $t10 wait 0xe601ccbc blocked 117939 k no sys _pthread_ksleep $t11 wait 0xe60b67bc blocked 747287 k no sys _pthread_ksleep $t12 wait 0xe60a7bbc blocked 686919 k no sys _pthread_ksleep
异常: Waiting to attach to process 49170 ... Successfully attached to cicsip. warning: Directory containing cicsip could not be determined. Apply 'use' command to initialize source path. Type 'help' for help. reading symbolic information ... stopped in evt._pthread_ksleep [/usr/lib/libpthreads.a] at 0xd00e2d4c ($t4) 0xd00e2d4c (_pthread_ksleep+0x9c) 80410014 lwz r2,0x14(r1) thread state-k wchan state-u k-tid mode held scope function $t1 wait 0xe60b32bc blocked 733945 k no sys _pthread_ksleep $t2 wait 0xe60097bc blocked 38679 k no sys _pthread_ksleep $t3 wait 0x32e7c904 running 91099 k no sys _ptrgl >$t4 run blocked 743665 k no sys _pthread_ksleep $t5 wait 0xf04805f4 running 127245 k no sys pthread_mutex_lock $t6 wait 0xf04805f4 running 200545 k no sys pthread_mutex_lock $t7 wait 0xf04805f4 running 200893 k no sys pthread_mutex_lock $t8 wait 0xf04805f4 running 732729 k no sys pthread_mutex_lock $t9 wait 0xf04805f4 running 757693 k no sys pthread_mutex_lock $t10 wait 0xf04805f4 running 117939 k no sys pthread_mutex_lock $t11 wait 0xf04805f4 running 747287 k no sys pthread_mutex_lock $t12 wait 0xf04805f4 running 686919 k no sys pthread_mutex_lock
通过分析以上信息和现象,发现正常和异常情况的cicsip进程信息区别很大,异常情况下cicsip的很多线程处在pthread_mutex_lock。 2.查看最近的console 日志,从4/29号6138交易连续出现了Abend code 为A57A,导致cicsas异常结束。 例如: ERZ014016E/0036 05/13/04 05:54:10 BCSSCICS : Transaction '6138', Abend 'A57A', at '????'. 并且在symrecs中出现了相关的异常信息。 SYMPTOMS = PIDS/5697D1720 LVLS/420 PTFS/ RIDS/ComIP_IntRecvBytes LINE/-1 MS/057003 MSN/14 SRC/11 PRCS/2097152 AB/A57A PID/42744 TID/1 TIME/040513055410 TAIST SECONDARY SYMPTOMS = PostMortem (Error Path is offset x'128' in ComIP_IntRecvBytes<ComIP_IntRecvGDS<ComIP_Receive<ComSU_ReceiveData<ComSU_GetFMHMessage<ComFS_APPCServ<TasTA_Exec<TasTA_Run<main) logging where error occurred SYMPTOMS = PIDS/5697D1720 LVLS/420 PTFS/@(#)comip, 15:47:27, May 5 2000 RIDS/ComIP_IntRecvBytes LINE/1731 MS/057003 MSN/14 SRC/11 PRCS/99 AB/A57A PID/42744 TID/1 TIME/040513055410 TAIST SECONDARY SYMPTOMS = * * * Internal inconsistency error * * * 分析: 1. 目前系统的版本如下: CICS 4.2.0.8,ENCINA 4.2.0.1。 目前cics 4.2的最高补丁如下: CICS 4.2.0.9,ENCINA 4.2.0.15。 2. 通过和ibm工程师共同分析,如果cicsip的很多线程处在pthread_mutex_lock,这样很可能会导致前台cics client 无法连接到cics server。 3. 如果需要进一步分析导致cicsip的很多线程处在pthread_mutex_lock的原因,则需要寻求IBM 实验室的技术支持。 4. 关于进一步分析A57A的问题,目前对参数进行如下调整: RD: SysDump=yes (原值:no) PCDump=no (原值:yes) ABDump=no (原值:yes) TD: 6138: TransDump=yes (原值:no) LD: 新增 TCPIPL1定义,其中端口号为1438。 如果再次出现A57A时将产生dump信息,从而通过分析交易的dump信息和应用程序的lis文件,来判断问题的原因。
|
建议: |
1. 基于cicsip的分析建议: 由于目前CICS产品的版本为4.2, IBM 实验室已经不再提供该版本的支持服务,所以建议升级到最新版本V5.1。 2. 针对目前cics的性能优化建议: (1) 把比较慢且允许等待的交易分成一类交易,从而使得这些交易不对其他执行时间短而且量大交易造成堵塞的现象。 (2) 由于某些前台的程序没有进行交易分类,所以导致后台使用CPMI交易进行执行,所以建议把CPMI的交易也进行分类。 (3) 调整 RD中MaxConsoleSize参数为一个合适的大小。 3. 需要密切关注应用程序中出现的A57A的问题,因为该问题会导致cicsas异常结束。 4. 目前建议网银的前置机使用1438的端口号,然后再继续观察系统。 |
当CICS REGION系统在空闲时cicsas个数从maxserver下降到minserver时,会出现cics region 异常down的现象。
Cics console中错误日志如下:
SERVICE_MESSAGE 12/05/04 12:22:56.115751675 xswork 78202/0001 : Traceback file '/var/cics_regions/xswork/dumps/dir1/cicsas78202.traceback' for transaction ' XA_CLOSE: Turned exception exc_e_illaddr into XAER_RMERR ERZ080035E/0805 12/05/04 12:22:56.127269406 xswork 78202/0001 : Abnormal termination U8035. XA_CLOSE returned a Resource Manager error when closing 'Sin gle Phase Informix' using XA_CLOSE string ''. ' SQLCODE 0, Unknown error messag e 0. ' ERZ010003I/0094 12/05/04 12:22:56.127556116 xswork 78202/0001 : CICS is p erforming region abnormal termination in process 'cicsas' ERZ052004I/0602 12/05/04 12:22:56.127992717 xswork 78202/0001 : Dump to ' SYSA0001.dmp' started. |
l AIX 5.2 ML04
l Informix ids 9.40.FC4
l Informix csdk 2.81.UC3 (/Informix/bin/check_version csdk)
l Informix conn 2.81.FC2R2
l DCE 3.2 +PTF 4
l Encina 5.1
l CICS 5.1 + CICS PTF1
l 一阶段提交
l RD中的MinServer=3 ,MaxServer=15
l RD中的ClassMaxTasks=1,1,1,1,1,1,1,1,1,8
l TD中的 CPMI: Tclass=10
l CICS通过Informix conn 访问 Informix IDS,采用tcpip连接方式
#include $include sqlca; main( void ) { $char jshzh[23]; char *CommArea; EXEC CICS ADDRESS EIB( dfheiptr ); EXEC CICS ADDRESS COMMAREA( CommArea ); memset(jshzh,0,sizeof(jshzh)); strcpy(jshzh,"1234567890123456789012"); jshzh[22]=''; printf("************ zh[%s]n",jshzh); EXEC SQL declare zh_cur1 cursor for select * from fhdgckfhz where zh=:jshzh for update; if (sqlca.sqlcode !=0) { printf("declare zh_cur1 err zh[%s]n",jshzh); EXEC CICS SYNCPOINT ROLLBACK; EXEC CICS RETURN; } EXEC SQL open zh_cur1; if (sqlca.sqlcode !=0) { printf("open zh_cur1 err sqlca.sqlcode[%s]n",sqlca.sqlcode); EXEC CICS SYNCPOINT ROLLBACK; EXEC CICS RETURN; } EXEC SQL close zh_cur1; if (sqlca.sqlcode !=0) { printf("close zh_cur1 err sqlca.sqlcode[%s]n",sqlca.sqlcode); EXEC CICS SYNCPOINT ROLLBACK; EXEC CICS RETURN; } EXEC SQL free zh_cur1; if (sqlca.sqlcode !=0) { printf("free zh_cur1 err sqlca.sqlcode[%s]n",sqlca.sqlcode); EXEC CICS SYNCPOINT ROLLBACK; EXEC CICS RETURN; } EXEC CICS RETURN; } |
通过测试各种交易,发现js3101交易每次测试都会出现cics异常。所以最终定位js3101交易,采用逐步注释的办法,发现问题与如下语句有关:
EXEC SQL declare zh_cur1 cursor for select * from fhdgckfhz where zh=:jshzh for update;
如果在应用中注释上述语句,系统运行正常。基于此种原因,我写了一个上述测试用例,进行如下测试。
l 采用上述的测试用例进行并发测试,使cicsas的并发数达到了Maxserver的个数。
l 应用程序中只定义cursor,不close和free cursor。
测试条件 | 测试结果 | |
1. | 一阶段提交; MinServer=3 ;MaxServer=15; 关键语句:EXEC SQL declare zh_cur1 cursor for select * from fhdgckfhz where zh=:jshzh for update; | 当cicsas个数从Maxserver下降时,会出现cics region 异常终止的现象。 |
2. | 一阶段提交; MinServer=3 ;MaxServer=15; 关键语句:EXEC SQL declare zh_cur1 cursor for select * from fhdgckfhz where zh=’12345678901234567890123’ for update; | 当cicsas个数从Maxserver下降时,cics region 表现正常。 |
3. | 一阶段提交; MinServer=15 ;MaxServer=15; 关键语句:EXEC SQL declare zh_cur1 cursor for select * from fhdgckfhz where zh=:jshzh for update; | 当cicsas个数从Maxserver下降时,cics region 表现正常。 |
4. | 两阶段提交; MinServer=3 ;MaxServer=15; 关键语句:EXEC SQL declare zh_cur1 cursor for select * from fhdgckfhz where zh=:jshzh for update; | 当cicsas个数从Maxserver下降时,cics region 表现正常;当会出现个别交易被hang的现象。 |
l 针对在应用程序中是否关闭和释放cursor的情况,我做了如下测试,结果如下:
IFX_AUTOFREE=1 | EXEC SQL set autofree enabled; | Close cursor | Free cursor | Cics region | |
1 | n | n | y | n | down |
2 | n | n | y | y | normal |
3 | n | y | y | n | normal |
4 | n | y | n | n | down |
5 | y | n | y | n | normal |
l 关于Enabling the AUTOFREE Feature
You can enable the AUTOFREE feature for an ESQL/C application in either of the following ways:
(1)Set the IFX_AUTOFREE environment variable to 1 (one).
When you use the IFX_AUTOFREE environment variable to enable the AUTOFREE feature, you automatically free cursor memory when cursors in any thread of the program are closed.
(2)Execute the SQL statement, SET AUTOFREE.
With the SET AUTOFREE statement, you can enable the AUTOFREE feature for a particular cursor. You can also enable or disable the feature in a particular connection or thread.
Warning: Be careful when you enable the AUTOFREE feature in legacy ESQL/C applications. If a legacy application uses the same cursor twice, it generates an error when it tries to open the cursor for the second time. When the AUTOFREE feature is enabled, the database server automatically frees the cursor when it closes it. Therefore,the cursor does not exist when the legacy application attempts to open it a second time, even though the application does not explicitly execute the FREE statement.
使用测试用例进行上述测试,从测试结果中发现
l 在cics和informix一阶段时:
如果minserver<maxserver
如果minserver=maxserver时,进行测试时,如果对定义和打开的cursor不close 和 free cursor,当cics region系统空闲时,cicsas个数从maxserver下降时,cics region 正常。
l 在cics和informix二阶段时:
如果minserver<maxserver
l 关于目前遇到的上述问题,已经提交给了IBM TSC的技术支持小组,并把相关的测试程序和环境发给他们了,IBM TSC并已经针对这个问题提交给了IBM 实验室。
l 关于应用程序是否是需要显示free cursor,我找到了如下资料:
With the OPTOFC feature disabled, a static cursor is freed when it is closed. When ESQL/C reaches a CLOSE statement for a static cursor,it actually sends a message to close the cursor and free memory associated with this cursor. However, dynamic cursors are not implicitly freed when they are closed. 另外: The default value of the OPTOFC environment variable is 0 (zero). 0 This value disables the OPTOFC feature for all threads of the application. |








