我们不能为新的 COBOL V6.2 编译器关闭 NUMCHECK 选项,因为我们不能信任数值变量的内容。问题是,当我们打开它时,它与我们之前在我们组织中使用的 COBOL 4 并不完全兼容。具体来说 - 当一个无符号压缩变量包含 X'123C' 时,COBOL 4 会接受它并让我们继续,但是带有 NUMCHECK(PAC,ABD) 的 COBOL 6.2 异常终止,并且只愿意接受 X'123F'。这对我们来说是一个关于汇编程序调用 COBOL 或从文件读取等的真正问题。是否有另一种选择,甚至可能是 PTF 来纠正这种行为?当 NUMCHECK 开启时,您能否指出其他类似的不兼容问题(如果存在)?谢谢!佐哈尔
2 回答
这是按记录工作的。我知道这不是你想听到的,但有时就是这样。您的应用程序异常终止,因为 NUMCHECK 编译选项检测到它认为无效的数据。
请注意,IBM COBOL 6.2 的NUMCLS安装选项控制 IF NUMERIC 类测试的行为,其隐式版本由 NUMCHECK 编译选项生成。如果您的打包数据是没有符号定义的,即
77 XYZ PIC 999 COMP-3.
那么文档表明 x'F' 的符号半字节是唯一将通过 IF NUMERIC 类测试的符号半字节。符号半字节的任何其他值都被视为无效。
摘自 IBM Enterprise COBOL 6.2 文档...
Table 1. NUMCLS(PRIM) and valid signs NUMPROC(NOPFD) NUMPROC(PFD) Signed C, D, F C, D, +0 (positive zero) Unsigned F F Table 2. NUMCLS(ALT) and valid signs NUMPROC(NOPFD) NUMPROC(PFD) Signed A to F C, D, +0 (positive zero) Unsigned F F
IBM COBOL 4.2的NUMCLS选项的文档措辞肯定不同......
使用 ALT 进行处理接受有效的十六进制 A 到 F。
使用 PRIM 进行处理接受有效的十六进制 C、D 和 F。
您可能想查看https://www.ibm.com/support/pages/node/604539#112918以查看是否有任何 PTF 适用于您的情况。
您可以尝试向 IBM 提出问题,但问题是:如果您有未签名的数据,则可以提出一个论点,即有一个符号半字节表示正 (x'C') 或负 (x'D') 符号是无效的。我怀疑这是 NUMCHECK 选项按其方式工作的部分原因。
可能的解决方案包括让您的汇编程序调用您的 COBOL 程序对它们传递的任何打包数据进行符号修复。可能是最后一个字节上的 OI。您可以为商店的 SORT 实用程序编写控制卡,以修复平面文件中的打包数据。您可以更改您的 COBOL 程序中未签名的打包数据项以进行签名。
这一切都取决于你想要什么样的行为。你说你不能相信你的数值变量的内容。如果这意味着您有时会使用 x'A' 而不是 x'C' 的符号半字节来表示正值,那么如果 NUMCLS(ALT) 有效,则可以使用 NUMPROC(NOPFD)。
如果 NUMCLS(ALT) 生效,另一种可能的解决方案是使用 NUMPROC(NOPFD) 进行编译并使用签名字段来最初保存您的数据。根据文档,将数据移动到未签名的字段将修复符号。请注意,NUMPROC(NOPFD) 的性能不如 NUMPROC(PFD)。
以下是我对哪些符号半字节导致 IF NUMERIC 测试为真的文档的理解的扩展。我无法对此进行测试,这只是我将文档的隐式语言转换为显式表的尝试。它确实突出了 IBM Enterprise COBOL 4.x 与 IBM Enterprise COBOL v5 及更高版本之间的差异。
SIGN COBOL 5+ COBOL 4
NUMCLS NUMPROC SIGNED NIBBLE NUMERIC NUMERIC
ALT NOPFD YES X'A' TRUE TRUE
ALT NOPFD YES X'B' TRUE TRUE
ALT NOPFD YES X'C' TRUE TRUE
ALT NOPFD YES X'D' TRUE TRUE
ALT NOPFD YES X'E' TRUE TRUE
ALT NOPFD YES X'F' TRUE TRUE
ALT NOPFD NO X'A' FALSE TRUE
ALT NOPFD NO X'B' FALSE TRUE
ALT NOPFD NO X'C' FALSE TRUE
ALT NOPFD NO X'D' FALSE TRUE
ALT NOPFD NO X'E' FALSE TRUE
ALT NOPFD NO X'F' TRUE TRUE
ALT PFD YES X'A' FALSE FALSE
ALT PFD YES X'B' FALSE FALSE
ALT PFD YES X'C' TRUE TRUE
ALT PFD YES X'D' TRUE TRUE
ALT PFD YES X'E' FALSE FALSE
ALT PFD YES X'F' FALSE FALSE
ALT PFD NO X'A' FALSE FALSE
ALT PFD NO X'B' FALSE FALSE
ALT PFD NO X'C' FALSE FALSE
ALT PFD NO X'D' FALSE FALSE
ALT PFD NO X'E' FALSE FALSE
ALT PFD NO X'F' TRUE TRUE
PRIM NOPFD YES X'A' FALSE FALSE
PRIM NOPFD YES X'B' FALSE FALSE
PRIM NOPFD YES X'C' TRUE TRUE
PRIM NOPFD YES X'D' TRUE TRUE
PRIM NOPFD YES X'E' FALSE FALSE
PRIM NOPFD YES X'F' TRUE TRUE
PRIM NOPFD NO X'A' FALSE FALSE
PRIM NOPFD NO X'B' FALSE FALSE
PRIM NOPFD NO X'C' FALSE TRUE
PRIM NOPFD NO X'D' FALSE TRUE
PRIM NOPFD NO X'E' FALSE FALSE
PRIM NOPFD NO X'F' TRUE TRUE
PRIM PFD YES X'A' FALSE FALSE
PRIM PFD YES X'B' FALSE FALSE
PRIM PFD YES X'C' TRUE TRUE
PRIM PFD YES X'D' TRUE TRUE
PRIM PFD YES X'E' FALSE FALSE
PRIM PFD YES X'F' FALSE FALSE
PRIM PFD NO X'A' FALSE FALSE
PRIM PFD NO X'B' FALSE FALSE
PRIM PFD NO X'C' FALSE FALSE
PRIM PFD NO X'D' FALSE FALSE
PRIM PFD NO X'E' FALSE FALSE
PRIM PFD NO X'F' TRUE TRUE
我还没有添加评论的声誉,所以我必须添加另一个答案。不过,我是 Enterprise COBOL 开发人员之一,我可以说的是 V4.2 文档不太清楚,V6 的措辞已经改变,但编译器的行为没有。两个编译器使用的行为与上面 cschneid 表中的 V5 列相匹配。
对于数字类测试,无符号打包和分区数据项始终需要 x'F' 的符号,无论 NUMPROC 或 NUMCLS 设置是什么。签名项始终允许 C 和 D,F 与 NUMPROC(NOPFD)(无论 NUMCLS 设置如何),A、B 和 E 仅针对 NUMCLS=ALT,NUMPROC(NOPFD)。NUMCLS 定制指南中的文档仅讨论签名类测试。
至于原始问题: NUMCHECK 的行为与 IS NUMERIC 测试完全一样,在这两种情况下,x'C' 的符号对于无符号数据项都被认为是无效的,并且 IS NUMERIC 测试或 NUMCHECK 会发现值不是数字/无效. 带有 x'C' 符号的所有其他 COBOL 语句(比较、算术、MOVE 等)的行为在 NUMPROC(PFD) 下未定义,并且可能在 V4/V6 之间、V6 中的 OPT 级别之间、ARCH 之间有所不同V6 中的级别等。在 NUMPROC(NOPFD) 和某些情况下 V4 中的 NUMPROC(MIG) 下(V6 中不支持 MIG),在使用该数据项中的值之前,无符号项的符号被强制为 0xF,所以这保证了某种行为,以及行为兼容性。然而,数字检查,