什么会导致 CICS 事务写出 CICS 分配的内存？答案

【问题标题】：What can cause CICS transaction to write out of CICS allocated memory?什么会导致 CICS 事务写出 CICS 分配的内存？
【发布时间】：2012-02-18 18:41:09
【问题描述】：

我在 Cobol 程序中使用 CICS，我注意到有时数据会从 CICS 内存中写入。它会导致数据损坏并且我的应用程序停止。我不知道它附加在哪里，所以我正在创建一个解析器来分析我的 Cobol 代码，以查找 CICS 使用的 COMMAREA 中可能存在的损坏。现在我检查了以下陈述：

EXEC CICS XCTL
EXEC CICS LINK
EXEC CICS RETURN TRANSID

对于每个，我检查发送的长度（在LENGTH 参数中声明）是否不大于发送的COMMAREA。然后我检查DFHCOMMAREA，在接收程序中是否大于发送COMMAREA（根据这个文档http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=%2Fcom.ibm.cics.ts31.doc%2Fdfhp3%2Fdfhp37t.htm）：

接收数据区不必与原始通信区长度相同；如果只需要访问数据的第一部分，则新数据区可以更短。但是，它不能长于通过的通信区域的长度。如果是这样，您的事务可能会无意中尝试读取已传递区域之外的数据。它还可能覆盖区域外的数据，这可能导致 CICS 异常终止。

现在，我想知道我应该解析哪些其他内容以检测内存覆盖？

【问题讨论】：

编写一个健壮的 COBOL 解析器是一项艰巨的工作。如果您使用的是 IBM Enterprise COBOL，我建议您探索使用编译器 ADATA 选项来生成 AST 并从那里开始。检测边界错误所需的静态代码分析类型在技术上不可能完全正确。静态分析基于程序的句法结构，而不是程序的语义，因此几乎不可能确定实际的运行时行为。
不幸的是，我正在使用 Microfocus NetExpress 编译器。而且，事实上，在静态分析中很难确定语义。实际上，我正在尝试找出可以在代码中完成的所有“路径”，并确定其中一些是否会产生错误。

标签： memory cobol overwrite cics microfocus

【解决方案1】：

当您使用 Micro Focus COBOL 时，您可以设置 memory_strategy 可调参数（或 CBL_MEM_STRATEGY API），通过允许运行时以各种不同方式保护内存来帮助您分析错误发生的位置。

内存也可以通过“CBL_MEM_VALIDATE”调用来验证。

可以做的另一件事是使用跟踪支持...查找 CTF (Consolidated Tracing Facility)。这将使您了解发生错误时代码所在的位置。

一些对你有帮助的参考资料；

http://kb.microfocus.com/display/4/kb/article.aspx?aid=31645

http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.eclipse.infocenter.studee60win.sp02ws01%2FHRRTRHRTCF0O.html

http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.eclipse.infocenter.studee60ux.sp02ws01%2FGUID-762085AC-8396-4D71-9CC1-6231551D3AEE.html

【讨论】：

【解决方案2】：

对于数据传递边界检查，始终使用transclusion，在 COBOL 中称为 COPYCODE 或 COPYBOOK。在复制代码中传递根数据元素，并在调用者和被调用程序中编译相同的版本。这个 COPYCODE 是被调用程序的一种契约，所以最好有一个命名约定将它们联系在一起。为确保它们是同步的，每当您更改 COPYCODE 时，请重新编译所有引用它的程序。

此外，SSRANGE 的使用也很棒（但有人已经提到过）。

【讨论】：

【解决方案3】：

NealB 有一个good idea。我建议你也看看STGPROT 和RENTPGM CICS system initialization parameters。

【讨论】：

感谢您的回答。我会看看我是否可以使用这些参数，我使用的是 Unikix 环境而不是 IBM，我不知道它们是否也存在。

【解决方案4】：

当 CICS 程序开始在整个内存中写入时，它不仅会“停止工作”，而且可能也让 CICS 区域崩溃！

如果您确定在 LINKs 和 XCTLs 上正确设置了 LENGTH 并且您是将COMMAREA 接收到该大小的链接记录（EIBCALEN）中，那么您应该没事。

我建议您设置编译器，而不是尝试解析您的 COBOL 程序边界检查选项。您遇到的问题很可能与超出工作存储表范围的索引或下标。试图检测这类通过静态分析的编程错误一般不是很有效的。

设置界限检查应该检测超出范围的内存引用，发出诊断消息日志，然后终止您的程序在它使整个 CICS 区域崩溃之前。记录的消息应该指向您发生越界引用的源代码行。

查看SSRANGE 编译时间选项。确保它已设置并且您的 CICS 区域使用CHECK(ON) 运行启用了 LE 的程序。

这应该会超出内存范围参考很快。

【讨论】：

好的，谢谢你的提示，我会试着看看它是如何工作的。实际上我工作的目的是解析 Cobol 程序（不运行），而不是使用 CICS 日志。所以我会尝试找到一种方法，在我的解析器中添加来自 CICS 的检查工具。