COBOL 中的 CICS 程序堆栈

Posted

技术标签:

【中文标题】COBOL 中的 CICS 程序堆栈【英文标题】:CICS Program Stack in COBOL 【发布时间】:2015-05-08 09:38:19 【问题描述】:

有没有办法在调用堆栈中识别程序名称? 即,我有一个 PGM X 链接到 PGM B,而这个链接到 PGM C,然后,在 C 中,我想知道哪个程序发起调用 (PGM X)?

【问题讨论】:

你为什么要这样做?我还假设答案并不总是 PGM A,因为有时 PGM Z 调用/链接到 PGM B。它是 CALL 还是 LINK?你想知道什么,PGM B的CALLer的program-id,loadmember的名字,什么? 1- 我的一位同事遇到了这个“问题”,因为他想记录初始呼叫者 ID。 2-你猜对了!如果呼叫者总是 PGM A,我们就没有“问题” 3- 这是一个 LINK。 4- 如果情况相同。 你需要澄清你(他们的)问题。如果答案总是 PGM A,那么就没有问题。大概不是这样,但问题没有说。是使用 CALL 还是 LINK?或者两者兼而有之?还是 XCTL?如果是 CALL,是静态 CALL 还是动态 CALL?虽然回想起来有很多方法可以做到这一点,但最好的办法是从初始程序中传递所需的日志信息。 我想我回答了你对我之前评论的疑问,但是,尽管如此:这是一个链接;最初的调用者并不总是相同的,是的,我也说过,但我们仍然想知道是否没有“系统”方式! 信息不应该在 cmets 中,它们是短暂的。所有信息都应该在问题/答案本身中。您的问题正在“搁置”过程中,因为其中缺少此类信息。正如@cschneid 所暗示的,有几种方法可以做到这一点。虽然可靠,但它并不简单,并且会比从初始调用者传递数据影响性能数量级。如果您可以使用请求的信息更新您的问题,并说明为什么自动方式是最好的,那么您会有所收获,但这不是一个好方法。 【参考方案1】:

您可以这样做,但需要一点汇编程序。本质上,您需要查找保存区域并在返回地址上执行 CSVQUERY,这将为您提供拥有该保存区域的模块的名称。

有一些怪癖,您需要注意 Cobol 运行时模块(以 IGZ 为前缀)和/或语言环境模块(以 CEE 为前缀)。当你进行 Cobol 调用时,它会调用一个运行时模块,然后调用你调用的程序。

此外,这不会识别执行 E.C. LINK 或 E.C. XCTL 的程序,只会识别使用 OS 保存区域约定的 Cobol Call 调用。

例子:

CSVQUERY SEARCH=JPALPA,INADDR=<R14_from_savearea>,OUTEPNM=<module_name_output>,MF=(E,PLIST)

对保存区域链上的每个返回地址重复执行此操作,您将知道所有调用者。

【讨论】:

【参考方案2】:

如果您在 CICS 中,您可以执行 EXEC CICS ASSIGN 并使用 PROGRAM 选项获取当前程序的名称,以及使用 INVOKINGPROG 链接到它的程序的名称。在这种情况下,这将为您提供程序 C 和程序 B。

要获得原始的***别程序是比较困难的。您可以查询当前事务 (EIBTRNID) 以获取正在运行的程序,但如果您已被路由到某个地方,那么它将不是程序 X,而是 DFHMIRS。

【讨论】:

【参考方案3】:

没有支持的方式来做到这一点。有些人尝试追逐保存区域并遍历可执行代码以确定其名称,但我怀疑一切都以眼泪告终。

一个问题是您无法保证 LINK 或 XCTL 是如何实现的。在动态调用的情况下,您可能能够遵循保存区域链,但是您需要弄清楚如何识别模块。仅使用 COBOL 可能无法做到这一点。

【讨论】:

谢谢@cschneid。我是这么想的,但值得一问,我们永远不知道!

以上是关于COBOL 中的 CICS 程序堆栈的主要内容,如果未能解决你的问题,请参考以下文章

在 COBOL-CICS-DB2 中,如何确定银行账户是不是已休眠/关闭?

在 z/OS CICS 中,执行 EMP 的 COBOL 程序能否检索在 TASK 期间执行的 EMP 的结果?

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

z/OS 如何调用 Web 服务? [关闭]

CICS 子程序

Z/OS 中 COBOL 嵌套程序与子程序有啥区别