ConfusedDay

无神论说我相信因为我可以证明，有神论说我相信因为你无法否定。

cics region在创建的时候就会在sfs_server(或者其他结构文件系统，如DB2)中创建7个队列相关的文件：

region_namecicstdqlgfile
region_namecicstdqphfile
region_namecicstdqnofile
region_namecicsnrectsqfile
region_namecicsrectsqfile
region_namecicsnlqfile
region_namecicsplqfile

也就是TDQ(Transient Data Queues)瞬时数据队列有三个文件，TSQ(Temporary Storage Queues)临时存储器队列有两个文件，LQ本地队列(Local Queues)两个文件。

分别是： 

逻辑上可恢复的瞬时数据队列
物理上可恢复的瞬时数据队列
不可恢复的瞬时数据队列
不可恢复辅助临时存储器队列
可恢复辅助临时存储器队列
本地排队的不受保护启动请求
本地排队的受保护启动请求

若是以前创建过相同名称的region却又因为种种原因没有删除sfs_server中的相关队列文件，再创建此region时会报错提示有错误发生，且不能创建此region。

人家放假要么回老家,要么旅游,要么结婚,要么打游戏。我放假是回老家,旅游,结婚,打游戏一起来...

昨天给客户写巡检报告，猛然遇到一个奇怪的问题，cicssfmt后的cics region的状态出现了10:04:00的时间。由于默认情况下statistics统计是每隔3小时统计一次，怎么会出现04分这个时间呢？而且前后时间也都是按照每隔3小时正常收集信息。

于是问了jae(哎，现在遇到问题第一反映是找jae，第二反映是先不找先分析，第三反映就是还是问问jae)。 jae怀疑有人工启动 statistics 程序的情况，导致当时多增加了一次统计。回头还是觉得不是很实在，客户对cics不是很熟悉。一般查看状态都是只是使用cicstail或者lssrc来检查。cicsterm从来不用。若是程序里调用的话有不可能仅仅是1个时间有问题。难道是当时系统时间的问题？查了一堆资料后无果睡觉去了。
今天一大早无聊的继续看看昨天format后的statistics文件。却偶然间发现了问题：出现0...

TXseries/CICS 也学了一阵了，但是总觉的还有很多东西要跟进。而若是要更深入的了解TXSeries/CICS我看开发必然是个必须通过的槛。

大致了解了下， TXseries/CICS的开发可以使用多种语言(但是不同的操作系统不一定支持所有的开发)，如：COBOL、C/C++、PL/I、Java等等。基本的用法当然是使用CICS的API了，但是CICS的API还是比较有趣的，CICS InforCenter里描述是CICS API Command。实际上它确实像(或者本来就是)嵌在程序代码中的命令。

我本来以为CICS  API会像大多数API一样提供一些参数和函数去调用。结果CICS API的调用是用如下方式使用的，在代码中加入如下格式来调用：
EXEC CICS  command [op...

加班无事，随便记录最近一直困惑我的事...

我们看过中国式的结婚，中国式的离婚。这里写下的只是我对中国式婚礼的思考。

经历了漫漫的户口的磨难我和草终于要结婚了。我们计划着一个回家旅游的婚礼。是的，回家加旅游，这对于我们俩这种从中学就早恋现在却一起在外地打拼的我们有着别人意想不到的意义。然而随着回家的临近，我却越来越紧张开来。我是那么的惧怕中国式的婚礼。

中国人应该怎么结婚？没有统一的答案，我们没有统一的宗教信仰，因此不可能有个仪式化的宗教过程在类似教堂的地方举办；我们也没有继承上一辈的结婚方式，因为我们不可能再拿个红本子被几段毛氏语录；我们甚至没有真正流传并流行的结婚礼仪，因为这一切都估计在一场场外来内在的战争和运动所遗弃。而这只是婚姻的部分，别忘了婚礼只是婚姻的矢量前的一个点而已。

...

昨日在客户处发现CICS总是在启动时包ERZ052011W，虽然只是个W(warning)并非E(Error)但是由于一开始就warning，加上数量比较多，很影响我的心情，估计客户若是知道这个不是CICS正常启动的信息，会比我更不爽的。 (:D)
首先信息信息如下：
ERZ052011W/1704 08/08/07 17:09:48 SZLT01 : Unable to access dump directory entry 'XXXX'
看字面意思也就知道了，dump下的xxxx这个目录不能访问，但是为什么有这个目录呢？我开始认为既然是开始启动就包，一定是此CICS region的某个database的stanza文件对region做了某些设置，但是在grep XXXX database/*/*.stanza后并没有发现类似的定义，于是我的思路陷入的死循环中，不断的想在CICS的启动前配置文件里找问题。最后只好又问老大jae，jae看了信息认为是应用报的错，应用需要访问这个目录。应用又是通过CICS来访问的，因此这个xxxx目录一定是没有cics用户的访问权限，所以有警告。我到dumps目录下一看，里面的一堆文件果然权限有问题。修改权限后走人(因为上线系统无法重启region)。
但是今天早上忽然觉得有问题 ，既然是应用的错误，为什么会在region启动的时候警告呢？在测试机上同样在cics region目录的dumps目录下建了几个权限777的文件，但是启动region后发现日志里发现了同样的警告信息，看来其实也未必是应用的问题，主要是cics region启动的时候会检查dumps目录下的内容，若是又非目录或者权限有问题，都会有这个警告。客户那里dumps目录下的一堆确都是文件，看来这个问题在下次启动时估计还是会重现的。

Txservies/CICS运行时会将很多运行信息写入到文件,主要的有console.NNNNNN文件,CSMT文件。当然也还有一些trace、core、或者是xa_NULLNNNNN.trc、symrecs之类的其他分析文件。
在主要的信息文件里(console.NNNNNN)，CICS的信息主要分为三个种类I(information)/W(warning)/E(Error),这些信息大部分以ERZmmmnnnt/MSN格式标识。其中ERZ为固定字符(不知道是什么英文的缩写，挺奇怪的)。mmm为3个数字，是CICS的模块标识。nnn也同样是3个数字组成，主要是用来更详细的细分模块操作。t就是主要由三种种类的首字母组成：I W E。最后的MSN实际上也是一串数字，主要是表示CICS code中报出此信息的具体位置（如何知道这个具体位置还不是很明确，但是知道首先在编译时要使用cicstcl的s参数，以便获取源程序列表文件：*.lst才能有用）。
此外CICS在不正常情况下还会有code return。这些code以Amma（四个字符）或者Ummnn（五个字符）的样式出现，若是以A开头意味着这个错误还是不幸中的万幸，cics region还不会因为这个错误而down下来。但是有可能cicsas会受到影响down掉，当然cicsam会再生成一个cicsas的。若是以U开头，那意味着呵呵，你的region就要完蛋了。
Amma中的mm其实和ERZmmmnnnt/MSN中的mm是同样为CICS的模块标识,只是此处的mm多为2位数。譬如:
ERZ014016E/0036 07/30/07 09:38:31.688434418 [RegionName] 6074432/0006      : Transaction 'CPMI', Abend 'A147', at '????'.
可以看见他们实际上是对应的，而最后一个数字则是详细表示功能便于分析错误。在此例中14指CICS中的Task Control Module(任务控制模块)他表明你的一个交易回滚了,这个操作是由CICS Task Control Module来控制,因此报出这个错误。但是显然这只是一个现象，太多原因造成这种错误返回，但是一般是交易写的有问题，比如前后台的交易接口不匹配。只能从程序入手来查问题，或者查看下日志前些时间的错误，很可能这个交易回滚是由先前错误所造成的。
Ummnn中的mm当然还是CICS模块标识,nn也是细化问题,但是估计细化的太多了,需要有两位来表示。最常见的是:
ERZ080005E/0801 08/23/07 17:05:50.720483201 [RegionName] 1507558/0001      : Abnormal termination U8005.  XA_OPEN returned a Resource Manager error when opening 'Oracle_XA' using XA_OPEN string Oracle_XA+Acc=#/####/######+SesTm=120'.
遇到这样的错误，那意味这你的region马上就要宕了，080是CICS Region database modules下的RegXA Product Definitions (XAD) Class Module，也就是说你在/var/cics_servers/[RegionName]/database/XAD/XAD.stanza文件中你定义的东西有问题，所以会报这个错，若是你的系统一直运行正常，那么当然不可能定义错误了。这就说明在报信息的当时CICS和XAD.stanza定义的XA Product(多为支持XA的数据库)连接有问题，这时候就可以抛开CICS，去寻找后台数据库、网络、或者数据库客户端的一些问题了。