who am i ... i'm back.
分类：
2008-05-22 18:17:27
刘睿
使用CICS/TXSeries开发设计一个大型的应用系统，应该注意以下要点：
1. 应用设计模式问题
2. 参数配置
3. 发生问题时如何处理
下面分别予以说明。
设计模式问题指在应用设计上需做出适当调整的问题，其原因在于没有考虑到CICS/TXSeries的某些用法带来的副作用。主要分为以下两类：
l 分布式调用(LINK/START)的设计
l CICS守护程序的设计
l 参数调整(包括交易分类)
在进行跨域LINK调用时，如果不使用SYNCONRETURN选项，同ECI程序使用扩展调用效果一样，被调用的程序不能自己发出同步点请求(SYNCPOINT)，而且要等待主调程序发出同步点请求(SYNCPOINT)后，被调用的程序占用的cicsas才能被释放。这种情况可能导致一些cicsas数目吃紧，交易超时等问题。
在设计CICS/TXSeries跨域调用时，要考虑到采用异步方式会带来的副作用(如果采用以异步见长的MQSeries则无此副作用)，这些副作用包括：
l 在被调方会有一个镜像CPMI交易产生的任务，占领一个cicsas的位置，直到主调方发出同步点请求(SYNCPOINT)。CICS如此设计是个历史 原因，CICS异步启动的要求是在另一个终端异步启动交易，而且在实施同步点请求(SYNCPOINT)之前可以多次使用START传输数据到该终端。这 个问题可能造成cicsas数目吃紧，交易超时，并产生ATNI错误信息。
l 在进行同步时，涉及到一个分布式的同步问题，造成响应时间长，并可导致A27K异常中断。A27K错误信息的原因是同步时的通信故障：比如远端的CICS 域不响应或者中断(通信错误15a00002/15a00102)，Client停止响应(通信错误15a00007/a0000100)，被调方 CICS域忙引起主调方超时(通信错误15a00007/a0000100)。
解决问题的办法是：
l 更改跨域的异步调用(CICS START)为同步调用(CICS LINK SYNCONRETURN)，可以在被调方自己实施必要的异步调用(CICS START)。
l 给所有涉及分布式调用的交易设置TD:Timeout(单位：分钟。参考建议3-5分钟)，TD:DeadLockTimeout(单位：秒。参考建议180 - 300秒)属性，RD:XPRecvTimeout (单位：秒。参考建议60 - 180秒)。只有这样才能有效避免远端CICS域繁忙和网络引起的通信超时。
l 设置交易分类。
CICS有多种超时设置，发生作用的时间很复杂，一般来说：
l TD:Timeout在主动发出ISC请求时发生作用。
l RD:XPRecvTimeout在被动和异步时发生作用。
LINK和START调用的等待情况比较如下：
l 使用跨系统的START调用时：如果使用NOCHECK选项，则不会等待，但是在发出同步点请求(SYNCPOINT)时会等待远端交易启动。任何超时可能产生ATNI和A27K Abend。当然，如果START调用时没有NOCHECK选项，则将等待并能够得到一定的返回码。
l 使用LINK调用时：只有对方执行完毕，才能返回。注意使用本域的LINK调用时，相当于在一个程序中运行。被调用的程序如果发生Abend，主调程序一定Abend。
所以在跨系统的调用时，使用LINK调用，在大部分情况下可以根据返回值来取得信息。LINK和START调用的主要返回值解释如下：
1、LINK错误码分析
INVREQ(请求非法)
交易状态不对(有无SYNCONRETURN混用)
TRANSID全空
LENGERR
DATALENGTH选项为负值
DATALENGTH选项比LENGTH选项长
NOTAUTH
权限问题
使用了SYSID选项，但是RSLCheck没有设置为NONE
PGMIDERR
PD不存在
PD被disabled.
ROLLEDBACK
被LINK的程序无法执行syncpoint
SYSIDERR
CD不存在或错误
对方域不存在或已经宕机
网络不通
在本地TD:timeout时，远端交易还在队列
通信错误码：15a00002/15a00102
TERMERR
会话失败，TRANSID不存在
在本地TD:timeout时，远端交易还在运行。通信错误码：15a00007/a0000100
RD:MaxTClassLim引起的Reject。通信错误码：15a00007/84b6031
2、START错误码分析
INVREQ(请求非法)
Hours超范围
Minutes超范围
Seconds超范围
指定REQID但是该TSQ已经存在(在Pool不足时可能出现)
IOERR
SFS满
ISCINVREQ
ISC失败
LENGERR
使用LENGTH(0).
NOTAUTH
权限不足
使用了SYSID选项，但是RSLCheck没有设置为NONE
SYSIDERR
CD不存在或错误
对方域不存在或已经宕机
网络不通
通信错误码：15a00002/15a00102
TERMIDERR
TERMID选项非法
TRANSIDERR
TRANSID选项非法
在使用LINK进行CICS ISC调用时，应当注意恰当的使用LENGTH和DATALENGTH选项。LENGTH选项是必须的，指出通信区的长度。但是发送LINK调用请求时， 经常有请求数据的长度小于返回数据的长度的情况，如果这样的话，请求数据的传输就不需要有LENGTH指定的那么大。因此，还增加了一个可选的参数 DATALENGTH，指明请求数据的长度。恰当使用DATALENGTH选项经常可以减少网络流量，从而提高系统的性能。
值得注意的是，在ECI客户程序中，只能指定LENGTH，不能指定DATALENGTH。实际上如果把ECI的通信区全部请空清空成二进制零，系统将自动计算“DATALENGTH”，即从结尾算起的二进制零不会进行网络传输。
在设计CICS/TXSeries守护程序时，必须考虑到以下要点：
l 守护程序必须得到保护，不能异常退出。
l 守护程序不能长时间等待网络通信(比如分布式同步的操作)。
针对保护守护程序异常退出的问题：可以使用Abend Handler捕获异常(采用EXEC CICS HANDLE ABEND PROGRAM)。在程序调用的各个级别都可以设置，发生Abend时，CICS会逐级寻找Abend Handler，如果没有，则提交给默认的Abend Handler（默认的一般是做DUMP）。Abend Handler基本上如同正常的CICS程序，但如果采用”EXEC CICS ABEND”结束，则再调用默认的Abend Handler。
注意，无法从Abend Handler程序中返回到发生Abend的程序。
针对保护守护程序长时间等待网络通信问题：其实不应该在守护程序中直接启动远端交易，无论采用同步还是异步方式。正确的办法是在守护程序中异步启动一个本地交易，该本地交易再启动远端交易(采用同步还是异步方式都可以)，再结合超时设置。
对于比较大型的TXSeries系统，注意调整以下参数：
l 内存池调整
l 交易分类
l 交易程序驻留内存
l cicsas数/MaxServer数
l 系统参数
在TXSeries的RD中有三种内存池大小设置，包括：
l MaxRegionPool，是region自己使用的内存。如果cicsas数和连接数很多时，会使用大量的MaxRegionPool来建立CICS内部对象。默认是2M。
l MaxTSHPool，是共享内存总量。应用程序使用GETMAIN SHARED就会在这个内存池中分配空间。还有些共享对象也会使用此内存池。默认是1M。
l MaxTaskPrivatePool，每个cicsas的私有内存池，应用程序使用GETMAIN分配的内存在这个内存池中。每个cicsas启动时预 先分配该内存池。举例，如果该值设置为10M，MaxServers等于20，如果20个cicsas都启动，将耗费200M内存。默认是1M。
可以使用交易CST2来观察内存池的使用情况，酌情进行调整。但是每次调整必须重新启动域。对较大的系统一些经验值如下：MaxRegionPool=50M，MaxTSHPool=15M + GETMAIN SHARED量，MaxTaskPrivatePool=1M + GETMAIN量(无SHARED选项)。
注意：
l 如果使用了GETMAIN SHARED，或者malloc，用完必须从应用释放内存。
l 如果CICS的内存池发生紧缺，会重复报出”CICS is under stress,Short in xxx storage”信息。这时应该提高内存池的大小，并重新冷启动CICS域。
通过使用交易分类的方法，可以保证不同种类的交易互不影响，还有利于鉴别错误，并对region起到保护作用。CICS交易(TD)可以分为十类。目的在于限制某一种或某几种交易执行和排队的个数。防止一类交易的爆发或错误占满所有cicsas，影响整个region。
修改TD定义中某个交易的TClass参数，可以将该交易归于某一类。该数值为1至10。缺省值为none，表示没有分类。没有分类的交易只受到RD中MaxServers参数的限制，即受到cicsas数目的限制。
例如：RD定义中的ClassMaxTasks=10,10,20,1,1,1,5,10,10,30 规定了每一类交易可以运行的上限，自左向右为第1类至第10类。RD定义中的ClassMaxTaskLim=1,1,1,0,0,0,5,10,5,10 规定了每一类交易可以排队的上限数目减1。当正在运行的数目达到了ClassMaxTasks限制后，新的改类交易请求在队列中进行排队。如果队列达到上限，交易被region拒绝，可能出现Abend A141。
cicsupdate –c rd –r $CICSREGION \
ClassMaxTasks=10,10,20,1,1,1,5,10,10,30 \
ClassMaxTaskLim=1,1,1,0,0,0,5,10,5,10 \
MaxRegionPool=50000000 \
MaxTaskPrivatePool=4194304 \
MaxTSHPool=20971520
cicsupdate -c td -r $CICSREGION -P CAIP Permanent=no
cicsupdate -c td -r $CICSREGION -P CAIP Permanent=yes TClass=1
cicsupdate -c td -r $CICSREGION -P IPSW Permanent=no
cicsupdate -c td -r $CICSREGION -P IPSW Permanent=yes TClass=2
cicsupdate -c td -r $CICSREGION -P CPMI Permanent=no
cicsupdate -c td -r $CICSREGION -P CPMI Permanent=yes TClass=10
在上面的例子当中，CAIP交易被归为第1类交易，该类交易可以同时运行10个，另外可以有0(1-1)个在队列中等待。队列总长度为10+1-1 =10。IPSW交易被归为第2类交易，该类交易可以同时运行10个，另外可以有0(1-1)个在队列中等待。队列总长度为10+1-1=10。CPMI 交易被归为第10类交易，该类交易可以同时运行30个，另外可以有9(10-1)个在队列中等待。队列总长度为30+10-1=39
另外，如果CICS程序比较大(例如10M以上)，反复调用时都从硬盘加载可能会使效率明显降低。这样可以设置PD属性使得程序驻留内存。但是要注意，驻留内存的程序的全局和静态量声明初始化代码不被执行，例如：
int a=1;
static int b=2;
对于cicsas数/MaxServer数的设置，一般最少要设到CPU个数的3倍。如果计算工作在本地执行，设置过多的cicsas数无助于吞吐量的提高，但可以增加平滑度，当然也消耗了更多的内存。如果本域只作为网关使用，则可以提高cicsas数，具体看实际情况。
针对HP和Solaris系统，TXSeries文档要求调整许多系统参数。对于大型系统，经验上要增加10倍。对Solaris系统，还应该调节进程调度表。
CICS系统发生问题时，无论是开发问题，还是一些版本的缺陷，都应该进行合理的信息收集工作，这样有利于分析错误原因。下面分以下几点进行讨论：
l ASRA DUMP问题
l 交易挂住或者运行时间过长问题
l 宕机问题
ASRA问题的本质是内存越界错误，可以通过分析交易DUMP文件，来找到错误的来源，具体做法如下：
l 使用如下方式编译源程序，取得列表文件(.lst)
cicstcl -s ...
或(对AIX)
xlc_r4 -c -qlist
l 设置TD：transaction dump选项：TransDump=yes
重新启动region，则可以产生ASRA DUMP文件
/var/cics_regions/
/var/cics_regions/
l 格式化transaction dump文件：
cicsdfmt -r
l 分析dump文件：
n 检查格式化文件????.fmt或traceback文件，找到出错所在偏移量（十六进制），判断是系统问题还是应用问题；若是应用问题，找出出错函数和该函数内出错位置相对偏移量；
n 对照.lst文件，找到出错点对应的行号（十进制）；
n 对照.c文件，找到程序出错内容，可仔细检查.lst或dump格式化文件或traceback文件中寄存器变量值等，检查出详细出错原因；
n 修改源程序，重新编译和测试。
分析交易挂住或者运行时间过长问题的方法本质上是要用showProcInfo和dbx等分析该程序是什么，正在做什么。
值得注意的是：
l TXSeries v5.1可以通过CEMT提供程序名称。
l 使用SNAPSHOT DUMP也可以给出许多信息。
l 使用交易分类可以给出很多鉴别不同交易的信息。
一般来说，要按照以下步骤查找原因：
l 使用cicsterm观察交易类型。
l 使用showProcinfo，truss，dbx等观察交易进程。还可以使用fuser或(fuser -x)看服务调用情况。必要时使用SNAPSHOT DUMP。
l 分析应用日志。
导致交易挂住或者运行时间过长问题的错误包括：
l 应用死循环。
l 数据库死锁。
l 客户程序使用了ECI扩展调用，并且没有提交或者回滚交易。
l 没有使用SYNCONRETUEN的LINK，并且没有提交或者回滚交易。
l 使用了跨系统的START(在被调用方，会有一个镜像CPMI交易，直到主调方同步点才会释放)。
CICS宕机的原因大体分为以下几类：
l 严重的程序错误导致系统内部严重错误
l 数据库连接错误(比如配置问题或者参数不足)
l 压力过大，系统或者CICS参数不足
l CICS产品缺陷
发生错误时，应该及时收取相关的日志文档。这些日志文档包括：
l console文件
l symrecs文件
l CSMT.out文件
l showProcInfo信息
l ps –ef信息
l ipcs -a信息（一般在使用CUC时需要）
许多错误可以通过这些日志文档得到准确定位，如果不能定位，可以提交IBM相关人员。
