调用C程序时COBOL MCH3601错误
在COBOL多次调用C程序时,有一个MCH3601。在第一个通话中,它运行良好,但随后失败了( MCH3601 )...我称之为c程序这样
CALL "C2" USING BY REFERENCE RESULT-STRING.
奇怪的是,如果我在呼叫失败之前调用其他C程序,那么失败的呼叫工作出色地。我熟悉C中的错误,您在其中放置了一个额外的printf,所有内容都有效,这是因为您分配了不良的内存,并且使用printf的事实在堆栈中分配了更多空间,以获取printf及其参数的返回地址,因此您的不良代码之所以有效,是因为溢出了printf的东西,因此没有分割故障。
我想这是类似的,但是在COBOL中,我有这样的变量声明
01 RESULT-STRING PIC X(20) VALUE ALL "X".
,因此我相信应该分配所需的资源。我也不知道AS400组装,在AS400中我有些无知,因此我正在努力解决这个问题。感谢您的帮助。
- 编辑
要回答评论: C程序返回int。它被定义为该
int main(int argc, char *argv[])
参数已获得
char * myarg=argv[1];
,然后将其他字符串复制到其中:
char * other_string[100];
...
//I null terminate it at byte 16
other_string[15]=0;
//the strcpy will copy only 15 bytes plus null char into the referenced arg
strncpy(myarg, other_string,16);
return 0;
因此,我相信我不会以任何方式在C中的参考COBOL变量之外写作。 COBOL代码很大,并且在不同的位置进行多个调用。
是否有可能在COBOL中溢出造成呼叫的返回地址或类似的东西?
there is a MCH3601 when calling a C program in COBOL multiple times. In the first calls, it works well, but then it fails with that error (MCH3601)... I call the C program like this
CALL "C2" USING BY REFERENCE RESULT-STRING.
The strange thing is that if I call a different C program before the call that fails, then the call that was failing works well. I am familiar with bugs in C in which you put an additional printf and everything works, and those are because you are allocating memory poorly and the fact of using a printf allocates more space in the stack for the return address of the printf and its parameters, so your bad code works because is overflowing over the printf stuff so no segmentation fault.
I guess this is something similar, but in cobol I have variable declarations like this
01 RESULT-STRING PIC X(20) VALUE ALL "X".
So I believe that should allocate the resources it needs. Also I have no idea about as400 assembly and I am somewhat ignorant in as400 so I am struggling to tackle the problem. Thanks for any help.
--EDIT
to answer comments:
The C program returns an int. It is defined as
int main(int argc, char *argv[])
The argument is obtained as
char * myarg=argv[1];
and then other string is copied into it:
char * other_string[100];
...
//I null terminate it at byte 16
other_string[15]=0;
//the strcpy will copy only 15 bytes plus null char into the referenced arg
strncpy(myarg, other_string,16);
return 0;
So I believe I am not writing over something outside the referenced cobol variable in C in any way. The Cobol code is rather large and it does multiple calls in different places.
Is it possible to have an overflow in Cobol that mess the return address of the call or something like that?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您的COBOL例程通过引用传递一个参数,即它传递了变量
result-string
的存储区域的地址。因此,您的C例程将接收单参数,即指针。您认为是包含传递的参数数量的整数, argc 实际上是通过参考传递的单个参数的地址。所有对 argv 数组的引用都使用arbitary存储地址,因为什么都没有传递。
您需要确保正确指定了C例程的入口点,因为您从COBOL调用
c2
。您的C例程应被声明为:仅当C程序是最高的例程(称为命令行)之类的命令行时,是否会通过计数器将其传递给所提供的参数。
更新
我已经编码了一个示例COBOL例程调用C例程,并通过参考传递一个参数。 Note 这是在Z/OS上完成的,而不是/400。您需要适应AS/400环境。
COBOL源
C源
C例程与以下粘合剂参数结合:
运行时运行时输出
,在输出(sysout)上看到以下行:
Your Cobol routine passes one parameter by reference, i.e. it passed the address of the storage area of variable
RESULT-STRING
. So, your C routine will receive a single parameter, i.e. a pointer.What you assume to be the integer containing the number of arguments passed, argc, is actually the address of the single parameter passed by reference. All the references to the argv array use arbitary storage adressses, since nothing has been passed.
You need to make sure that the entry point to the C routine is correctly specified, since you call
C2
from Cobol. Your C routine should be declared as:Only if the C program is the top-most routine, called form a command line like environment, will it be passed a counter, and an array of char pointers to the arguments given.
Update
I've coded a sample Cobol routine calling a C routine, passing one parameter by reference. Note this was done on z/OS, not AS/400. You man need to adjust to the AS/400 environment.
Cobol Source
C Source
The C routine was bound with the following BINDER parameters:
Runtime Output
When run, the following lines are seen on the output (SYSOUT):