什么会导致 CICS 事务写出 CICS 分配的内存？
我在 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 异常终止。
现在，我想知道还应该解析哪些内容才能检测内存覆盖？
I'm using CICS in Cobol program and I've noticed that sometimes data are written out of the CICS memory. It cause a data corruption and my application stop. I don't know where it append, so I'm creating a parser to analyse my Cobol code to look for possible corruption in COMMAREA used by CICS. Now I checked following statements :
EXEC CICS XCTL
EXEC CICS LINK
EXEC CICS RETURN TRANSID
For each, I check if sent length (declared in LENGTH parameter) is not greater than sent COMMAREA. Then I check if DFHCOMMAREA, in the receiving program is not greater than sent COMMAREA (according to this doc http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=%2Fcom.ibm.cics.ts31.doc%2Fdfhp3%2Fdfhp37t.htm) :
The receiving data area need not be of the same length as the original communication area; if access is required only to the first part of the data, the new data area can be shorter. However, it must not be longer than the length of the communication area being passed. If it is, your transaction may inadvertently attempt to read data outside the area that has been passed. It may also overwrite data outside the area, which could cause CICS to abend.
Now, I'm wondering what other things should I parse in order to detect memory overwritting?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
当您使用 Micro Focus COBOL 时，您可以设置 memory_strategy 可调参数（或 CBL_MEM_STRATEGY API），通过允许运行时以各种不同的方式保护内存来帮助您分析发生错误的位置。
内存也可以通过“CBL_MEM_VALIDATE”调用进行验证。
可以做的另一件事是使用跟踪支持...查找 CTF（统一跟踪工具）。这将使您了解发生错误时代码的位置。
一些对您有帮助的参考资料；
http://kb.microfocus.com/display/4/kb /article.aspx?aid=31645
http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.eclipse.infocenter.stuee60win.sp02ws01%2FHRRTRHRTCF0O.html
http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.eclipse.infocenter.stuee60ux.sp02ws01%2FGUID-762085AC-8396-4D71-9CC1-6231551D3AEE.html
As you are using Micro Focus COBOL, you could set the memory_strategy tunable (or the CBL_MEM_STRATEGY API) to help you analysis where the error is occurring by allowing the runtime to protect memory in various different ways.
Memory can also be validate via the "CBL_MEM_VALIDATE" call.
Another thing can do is use the tracing support... lookup CTF (Consolidated Tracing Facility). This will give you an idea where you code is at the time of the error.
Some References that will help you;
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
对于传递数据边界检查，始终使用 transclusion，在 COBOL 中称为 COPYCODE或抄写本。在复制代码中传递根数据元素，并在调用者和被调用程序中编译相同的版本。这个 COPYCODE 是被调用程序的契约，所以最好有一个命名约定将它们联系在一起。为了确保它们同步，每当您更改复制代码时，请重新编译引用它的所有程序。
另外，SSRANGE 的使用很棒（但有人已经提到过）。
For the passing-of-data bounds checking, always use transclusion, which in COBOL is called a COPYCODE or COPYBOOK. Pass the root data element in the copycode, and compile the same version in the caller and called program. This COPYCODE is sortof the contract for the called program, so it is a good idea to have a naming convention tying them together. To make sure they are in-sync, whenever you change the COPYCODE, recompile all programs that reference it.
Also, the use of SSRANGE is great (but someone already mentioned that).
NealB 有一个好主意。我建议您还查看 STGPROT和 RNTPGM CICS 系统初始化参数。
NealB has a good idea. I suggest you also look into the STGPROT and RENTPGM CICS system initialization parameters.
当 CICS 程序开始写入整个内存时，它不仅会“停止工作”，而且可能
CICS 区域也会崩溃！
如果您确定
LINK和XCTL上的LENGTH设置正确，并且您将
COMMAREA接收到该大小的链接记录 (EIBCALEN)，那么您应该没事。
我建议您设置编译器，而不是尝试解析您的 COBOL 程序
边界检查选项打开。您遇到的问题很可能与
超出工作存储表范围的索引或下标。尝试检测
通过静态分析这类编程错误一般不是很严重
有效的。
设置界限
检查应该检测到超出范围的内存引用，发出诊断消息
日志，然后终止你的程序
在整个 CICS 区域崩溃之前。记录的消息应该指出
发生越界引用的源代码行。
查看 SSRANGE 编译时选项。确保它已设置并且您的 CICS 区域
使用
CHECK(ON)运行启用 LE 的程序。这应该可以解决内存越界问题
参考资料很快。
When a CICS program starts writing all over memory it will not only "stop working" but possibly
crash the CICS region as well!
If you are sure that the
LENGTHis set properly onLINKs andXCTLs and that you arereceiving the
COMMAREAinto a linkage record of that size (EIBCALEN), then you shouldbe fine.
Rather than trying to parse your COBOL programs I suggest that you set compiler
bounds checking options on. The problem you are having is most likely related to
indexing or subscripting beyond the bounds of a working storage table. Attempting to detect
this class of programming error through static analysis is generally not very
effective.
Setting bounds
checking on should detect out of range memory references, issue a diagnostic message to
the log, and then and terminate your program
before it crashes the whole CICS region. The logged message should point you the the
source line where the out of bounds reference occured.
Check out the
SSRANGEcompile time option. Make sure it is set and that your CICS regionruns LE enabled programs with
CHECK(ON).This should nail out of bounds memory
references pretty quickly.