什么会导致 CI​​CS 事务写出 CICS 分配的内存？

Posted 2023-02-21

【中文标题】什么会导致 CI​​CS 事务写出 CICS 分配的内存？

【英文标题】：What can cause CICS transaction to write out of CICS allocated memory?

【发布时间】：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）：

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

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

【问题讨论】：

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

不幸的是，我正在使用 Microfocus NetExpress 编译器。而且，事实上，在静态分析中很难确定语义。实际上，我正在尝试找出可以在代码中完成的所有“路径”，并确定其中一些是否会产生错误。

【参考方案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 时，请重新编译所有引用它的程序。

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

【参考方案3】：

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

【讨论】：

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

【参考方案4】：

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

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

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

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

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

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

【讨论】：

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