请注意，“I”的定义（可能）由一位程序员编写，而 WS-SUB 的定义由另一位程序员编写（命名不同，VALUE 子句出于相同目的而不同）。
程序员 2 看起来像“老派”：PIC S9(4)，签名并占用了所有“适合”半字的数字。根据可能的值范围，S9(9) 可能“远远超过顶部”，但这些事情根本不关心程序员 1。
程序员 2 可能担心将 S9(9) COMP 用于需要（可能很多）少于 9999 个“事物”的事物。“在不更改现有代码的情况下，我将‘高效’”。在我看来，该字段不太可能被定义为无符号。
具有九位数字的 COMP/COMP-4 在用于计算时确实会降低性能。尝试“添加 1”到 9(9) 和 9(8) 和 9(10) 并比较生成的代码。如果您可以有九位数字，请使用 9(10) 进行定义，否则使用 9(8) 定义，如果您需要完整字词。
程序员 2 对此有所了解。
+ 0 的 COMPUTE 可能是故意的。为什么程序员 2 那样使用 COMPUTE（原始问题）？
现在它会变得复杂。
大型机上有两种“类型”的“二进制”字段：那些将包含受 PICture 子句限制的值（USAGE BINARY、COMP 和 COMP-4）；那些包含受字段大小限制的值（USAGE COMP-5）。
使用 BINARY/COMP/COMP-4，字段的大小由 PICture 确定，可以保存的值也是如此。PIC 9(4) 是一个半字，最大值为 9999。PIC S9(4) 是一个半字，其值为 -9999 到 +9999。
使用 COMP-5 (Native Binary)，PICture 只是决定字段的大小，字段的所有位都与字段的值相关。图 9(1) 至 9(4) 定义半字，图 9(5) 至 9(9) 定义全字，图 9(10) 至 9(18) 定义双字。PIC 9(1) 最多可容纳 65535，S9(1) -32,768 到 +32,767。
一切都很好。然后是编译器选项TRUNC。这有三个选项。STD，默认值，BIN 和 OPT。
BIN 可以认为影响最深远。BIN 使 BINARY/COMP/COMP-4 的行为类似于 COMP-5。实际上，一切都变成了 COMP-5。二进制字段的图片被忽略，除了确定字段的大小（奇怪的是，使用 ON SIZE ERROR，当超过 PICture 的最大值时“错误”）。IBM Enterprise Cobol 中的 Native Binary 主要（但不限于）生成“最慢”的代码。截断是字段大小（半字、全字、双字）。
默认情况下，STD 是“标准”截断。这将截断为“图片”。因此，它是“十进制”截断。
OPT 是为了“性能”。使用 OPT，编译器会以任何方式截断特定“代码序列”的最“高性能”。这可能意味着中间值和最终值可能具有“位设置”，这些“位”位于 PICture 的“范围之外”。但是，当用作源时，二进制字段将始终仅反映 PICture 指定的值，即使设置了“多余”位也是如此。
使用 OPT 时，所有二进制字段“符合 PICture”非常重要，这意味着代码绝不能依赖于 PICture 定义之外设置的位。
注意：即使使用了 OPT，OPTimizer（OPT(STD) 或 OPT(FULL)）仍然可以提供进一步的优化。
这一切都很好。
但是，如果您“混合”TRUNC 选项，或者如果 CALLing 程序中的二进制定义与 CALLed 程序中的不同，则很容易出现“pickle”。如果同一运行单元中的模块使用不同的 TRUNC 选项编译，或者如果文件上的二进制字段使用一个 TRUNC 选项写入，然后使用另一个读取，则可能会发生“混合”。
现在，我怀疑程序员 2 遇到了这样的事情：要么，使用 TRUNC(OPT)，他们注意到一个字段中的“多余位”并认为需要处理它们，或者，通过运行中的选项“混合” -unit 或“跨文件使用”他们注意到“多余的位”需要对其进行处理（即“删除混合”）。
程序员 2 开发了 COMPUTE A = B + 0 来“处理”特定问题（感知的或实际的），然后将其普遍应用到他们的工作中。
这是一种“猜测”，或者更好的是，一种与已知信息一起工作的“合理化”。
这是一个“假”修复。没有问题（TRUNC(OPT) 工作的正常方式）或正确的解决方案是跨模块/文件使用的 TRUNC 选项的“规范化”。
我不希望现在有很多人匆忙离开并将 COMPUTE A = B + 0 放入他们的代码中。首先，他们不知道自己为什么要这样做。对于延续，这是错误的做法。
当然，不要只是从您找到的任何这些中删除“+ 0”。如果存在 TRUNC 的“混合”，则程序可能会停止“工作”。
在一种情况下，我对 BINARY/COMP/COMP-4 使用了“加零”。这是在一个“米老鼠”程序中，这个程序没有任何目的，只是为了尝试一些东西。在这里，我将它用作“欺骗”优化器的方法，否则优化器可能会看到不变的值，因此会生成代码以使用文字结果，因为所有值在编译时都是已知的。（我从 PhilinOxford 获得的一种可能“更简洁”和更灵活的方法是在该领域使用 ACCEPT）。可以肯定的是，有问题的代码并非如此。