CICS 问题诊断介绍之初步检查（二）


内容
提要 本文叙述了CICS 问题诊断之初步检查的方法
正文 6.上次成功运行之后做过什么改变吗？
服务:
a. 你是否在CICS上安装了PTF？
b. 它安装成功了吗？还是你在安装过程中得到了错误信息？
c. 是否有应用在其他程序的补丁影响了CICS与该程序的接口？
硬件:
a. 你更换过硬件吗？
软件:
a. 你更改过软件吗？
b. 如果你安装了新的或者修改了应用程序，从以下输出中检查错误信息：
翻译器
编译器
汇编程序
链接编辑程序
管理:
a. 你是否改变了你的初始化过程，CICS系统初始化或者使参数无效，或者VTAM配置，例如通过JCL？
b. 在初始化过程中，CICS是否产生了错误信息？
c. 你是否安装了用CEDA定义的资源？
如果上次CICS中断的时候，已经做了定义却还没有安装，它们在中止和之后的启动中没有被保留下来。通常，CSD做了改变但是没有安装，热启动CICS时是不可见的。然而，如果这个改变是在一个group中，而这个group又在冷启动时指定的GRPLIST中，那它可以在启动时被有效的安装。（冷启动后，已被安装的改变就不可见了，除非它们在GRPLIST里的group中。）
如果系统初始化表中指定了START=AUTO，或者作为一个越过，你需要检查job log来发现上次CICS是怎样被启动的。
有关资源定义和安装方法的详细指导，请见《CICS Resource Definition Guide》。

7. 是否有特定的网络部分受到这个问题的影响？
a. 你能否指出这个问题影响了哪些网络中的特定部分？如果你能，从访问方法中查找一切解释的信息。即使没有信息被送回控制台，你也可以在CSNE log中找到一条。
b. 你是否做了一些与网络相关的改变？
c . 如果这个问题只影响了单独的一个终端，你的这个终端的定义正确吗？考虑使用的TERMINAL定义和TYPETERM定义是否正确。
d. 如果问题影响了几台终端，你能否确定一个因素是它们共有的？例如：
它们的TYPETERM定义是否相同？是的话，TYPETERM定义是否存在错误。
是否整个网络都受到了影响？如果是的话，CICS可能已经停了。

8. 这个应用以前成功的运行过吗？
a. 它上次成功运行以后，是否对应用做过改变？检查新增或改变的部分。
b. 你是否使用RDO建立或改变transaction, program, mapset。你必须在使用这些资源运行CICS区域前就安装它们的定义。
c. 如果你改变了任何map, 你是否已经建立了一个新的phase（TYPE=MAP)和一个新的DSECT（TYPE=DSECT），并且重新编译每个使用这个新DSECT的程序。使用CEMT命令：
CEMT SET PROGRAM(mapset) NEWCOPY
CEMT SET PROGRAM(all programs) NEWCOPY
d. 是否应用的所有功能以前都充分演习过？
设定错误发生时程序在做什么，检验那部分程序的源码。
如果一个程序在大多数以前的情况下都运行成功，检查所有错误发生时被处理的所有记录、屏幕数据、文件的内容。它们可能包含了一些不同寻常的数值，这些数值使程序中很少被使用的一个分支被调用。
e. 检查出错时应用是否成功的获得它要求的记录。
f. 检查出错时记录中所有field所包含的数据都是程序可以接受的格式。使用CICS dump做这个检测。
如果你能在测试系统中重现这个错误，你可以使用程序语言的调试工具和CEDF交易来检查数据和解决问题。

9. 应用以前从没有成功运行过。
如果你的应用程序还没有成功的运行过，仔细检查它看能否发现任何错误。
a. 检查翻译器、编译器、链接编辑程序的输出，看是否报错。
b. 检查应用的编码逻辑，故障的症状是否指出了失败的功能，因而指出了错误的编码段？
c. 如下是一些通常在应用中发现的程序错误列表：
CICS区域所写的地址错误。
过渡过程数据管理错误。
文件资源没有释放。
存储被程序破坏。
CICS要求的返回码被忽视。

多好的。。。。shala。。。

什么时间 你也满月阿。。。。也发银子吧。。。。

......
你找3毛要啊，她是首富！！！

打劫准备中。。。。。。