一、调试前的准备：别急着跑程序，先当个“侦探”

接到一个调试任务，尤其是别人写的复杂逻辑，千万别一头就扎进代码里。那跟跳进迷宫没区别。咱们得先当侦探，把现场勘查清楚。

第一，搞清楚“案发现场”。 这个程序是干嘛的？它处理的是什么业务？是计算利息，还是核对账单？输入的数据大概长什么样，预期的输出又应该是什么？这些信息，往往在程序开头的注释里，或者配套的需求文档里能找到蛛丝马迹。如果文档不全，那就去问熟悉这个业务的老同事，或者直接看程序里那些“硬编码”的业务规则数字和判断条件。

第二，找到“案发记录”。 程序报了什么错？是在哪一步报的？如果没报错，只是结果不对，那么不对的结果具体是什么？和正确结果差了多少？这个“差”，往往就是破案的关键线索。比如，一个金额总计少了，那很可能是在某个循环里，有条记录被意外跳过了。

第三，准备好你的“放大镜”和“记事本”。 在真正开始调试运行前，先在纸上或者文本编辑器里，把程序的主干逻辑画出来。不用多精美，就画几个框，标出主要的PERFORM段落、循环和关键判断（IF语句）。这能帮你建立全局观，知道程序大概是怎么“流”起来的。

二、核心武器：让程序自己“说话”——诊断输出（DISPLAY）的艺术

在COBOL的世界里，最朴实无华也最强大的调试工具，就是DISPLAY语句。它能让程序在运行过程中，把内部变量的状态“说”给你听。用好了它，大部分逻辑错误都无所遁形。

关键技巧1：像下围棋一样布点。 不要只在程序开头结尾DISPLAY。要在关键逻辑路径上“布点”。比如：

  • 在循环（PERFORM VARYING...）开始前，显示循环控制变量的初始值。
  • 在循环体内，每次循环都显示关键业务数据和累加值。
  • 在重要的IF、EVALUATE语句前后，显示判断条件和分支结果。
  • 在调用子程序（CALL）前后，显示传入参数和返回结果。

关键技巧2：输出信息要清晰可读。 别光秃秃地DISPLAY WS-AMOUNT。加上标签，让输出像日志一样。

DISPLAY ‘进入利息计算循环，当前索引: ‘ WS-INDEX
DISPLAY ‘本金: ‘ WS-PRINCIPAL ‘, 利率: ‘ WS-RATE
DISPLAY ‘计算前累计利息: ‘ WS-TOTAL-INTEREST
COMPUTE WS-INTEREST = WS-PRINCIPAL * WS-RATE
DISPLAY ‘本次利息: ‘ WS-INTEREST
COMPUTE WS-TOTAL-INTEREST = WS-TOTAL-INTEREST + WS-INTEREST
DISPLAY ‘计算后累计利息: ‘ WS-TOTAL-INTEREST

这样，当程序运行时，你就能看到一串清晰的流水账，立刻就能发现是某次计算错了，还是累加漏了。

让我们结合一个详细的例子来看： 技术栈： IBM COBOL for z/OS (与大多数COBOL环境兼容)

假设我们有一个程序，要读取一个客户交易文件，并按照账户号汇总交易金额，但汇总结果总是少了一部分。我们来模拟调试过程。

       IDENTIFICATION DIVISION.
       PROGRAM-ID. DEBUGDEMO.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  WS-INPUT-RECORD.
           05  WS-ACCT-NO         PIC X(10).
           05  WS-TRANS-AMOUNT    PIC S9(9)V99 COMP-3. *> 压缩十进制数
           05  FILLER             PIC X(68).
       01  WS-PREV-ACCT           PIC X(10) VALUE SPACES.
       01  WS-TOTAL-AMT           PIC S9(9)V99 VALUE ZERO.
       01  WS-GRAND-TOTAL         PIC S9(9)V99 VALUE ZERO.
       01  WS-EOF-SW              PIC X(3) VALUE ‘NO ‘.
           88  WS-EOF             VALUE ‘YES‘.
       PROCEDURE DIVISION.
           OPEN INPUT TRANSFILE
               OUTPUT REPORTFILE
           PERFORM UNTIL WS-EOF
               READ TRANSFILE INTO WS-INPUT-RECORD
                   AT END SET WS-EOF TO TRUE
                   NOT AT END
                       PERFORM 100-PROCESS-RECORD
               END-READ
           END-PERFORM
           PERFORM 200-FINALIZE-ACCT *> 处理最后一个账户
           CLOSE TRANSFILE REPORTFILE
           STOP RUN.
       100-PROCESS-RECORD.
      *> 关键调试点1：刚读入记录时，看看数据对不对
           DISPLAY ‘>>> 读入记录. 账号:‘ WS-ACCT-NO
                   ‘, 金额:‘ WS-TRANS-AMOUNT
      *> 判断是否切换到新账户
           IF WS-PREV-ACCT NOT = WS-ACCT-NO AND WS-PREV-ACCT NOT = SPACES
               PERFORM 200-FINALIZE-ACCT
               MOVE WS-ACCT-NO TO WS-PREV-ACCT
               MOVE ZERO TO WS-TOTAL-AMT
               DISPLAY ‘*** 切换到新账户: ‘ WS-ACCT-NO
           ELSE
               IF WS-PREV-ACCT = SPACES *> 第一条记录
                   MOVE WS-ACCT-NO TO WS-PREV-ACCT
                   DISPLAY ‘*** 开始处理第一个账户: ‘ WS-ACCT-NO
               END-IF
           END-IF
      *> 累加当前账户金额
           COMPUTE WS-TOTAL-AMT = WS-TOTAL-AMT + WS-TRANS-AMOUNT
      *> 关键调试点2：每次累加后，看小计变化
           DISPLAY ‘    累加后小计 WS-TOTAL-AMT=‘ WS-TOTAL-AMT
           .
       200-FINALIZE-ACCT.
      *> 关键调试点3：处理完一个账户时，输出结果
           IF WS-PREV-ACCT NOT = SPACES
               DISPLAY ‘=== 账户 [‘ WS-PREV-ACCT ‘] 汇总完成, 总额=‘
                       WS-TOTAL-AMT
               COMPUTE WS-GRAND-TOTAL = WS-GRAND-TOTAL + WS-TOTAL-AMT
               DISPLAY ‘    更新后总计 WS-GRAND-TOTAL=‘ WS-GRAND-TOTAL
               *> (这里通常会把WS-PREV-ACCT和WS-TOTAL-AMT写入报表文件)
               MOVE SPACES TO WS-PREV-ACCT *> 重置，准备下一个
           END-IF
           .

运行这个程序（假设有数据），DISPLAY的输出会像侦探的笔录一样，清晰地展示程序是如何一步步处理每个账户的。如果发现某个账户的“累加后小计”突然清零或跳跃，或者“切换到新账户”的日志没打出来，问题立刻就定位了。比如，如果文件不是按账号排序的，那么IF WS-PREV-ACCT NOT = WS-ACCT-NO这个判断逻辑就会出问题，导致汇总错误。通过DISPLAY日志，我们很容易就能发现：“咦，账号A还没汇总完，怎么又出现账号B了？哦，原来文件没排序！”

三、进阶工具：使用编译器和调试器的“官方外挂”

除了DISPLAY，现代COBOL环境（如IBM z/OS下的调试工具，或Micro Focus等PC平台COBOL）都提供了强大的交互式调试器。这就像给了你一个“时间控制器”，可以暂停时间，仔细查看世界的每一个细节。

核心功能：

  1. 设置断点： 让程序运行到指定行（比如某个复杂的计算语句前）自动暂停。这是最常用的功能。
  2. 单步执行： 让程序一行一行地走，你可以观察每一步之后所有变量的变化。
  3. 查看/修改变量： 在程序暂停时，不仅可以查看任何变量的当前值，有时还能临时修改它的值，来测试不同的逻辑路径。
  4. 监视点： 给某个变量设置监视，只要它的值一发生变化，程序就暂停。这对于查找谁在偷偷修改某个关键变量特别有用。

怎么用？ 以思路为主，具体操作因工具而异。当你用DISPLAY把问题范围缩小到一个段落或几十行代码后，就打开调试器，在可疑的COMPUTE或IF语句前设上断点。然后运行程序，等它停住。这时，你可以：

  • 看看所有工作变量（WS-开头）的值是否符合预期。
  • 用单步执行，走一遍IF语句，看它是否进入了你期望的分支。
  • 如果是一个循环出错，就在循环开始设断点，然后一次次“继续”，观察每次循环变量的变化规律。

结合示例： 假设我们在上面的例子中，发现WS-TOTAL-AMT在某个点被意外清零了，但DISPLAY没抓到这个瞬间。我们就可以在200-FINALIZE-ACCT段落中MOVE SPACES TO WS-PREV-ACCT这一行设置断点，并给WS-TOTAL-AMT设置监视点。一旦程序运行到这里，或者WS-TOTAL-AMT被改变，调试器就会暂停，我们就能看到完整的调用栈和变量状态，精确找到不该发生的清零操作是在哪里被触发的。

四、思维心法：像分解机器一样分解逻辑

面对极其复杂的业务逻辑（比如一个包含几十个条件判断的利息计算规则），最好的方法就是“分解”。

1. 模块化验证： 如果程序本身写得很模块化（用了很多PERFORM调用子段落），那太好了。你可以单独准备一份简单的测试数据，直接PERFORM调用那个最复杂的计算段落，在调用前后DISPLAY输入输出，验证这个“小机器”本身是否正确。

2. 搭建“脚手架”： 如果程序是一大坨，没怎么模块化。你可以主动为它“搭建脚手架”。即，把那段复杂的逻辑代码单独拷贝到一个新的测试程序里。然后，在测试程序里手工设置输入变量（MOVE固定的值到那些字段），运行它，看输出。这样就把问题从庞大的生产程序中隔离出来了。

3. 逻辑表格化： 对于复杂的EVALUATE或嵌套IF，画表格！把所有的条件组合和应有的结果列出来。然后，在调试时，让你的DISPLAY输出当前满足的是表格中哪一行的条件。这能极大避免思维混乱。

五、避坑指南与总结

应用场景： 这些方法适用于所有需要理解、验证或修复现有COBOL程序业务逻辑的场景，尤其是在缺乏完整文档、原始开发者已离职、或逻辑随业务变更多次后变得异常复杂的情况下。

技术优缺点：

  • DISPLAY调试法：
    • 优点： 简单直接，无需特殊工具，输出日志可留存复查，适合所有COBOL环境。是理解程序流程的绝佳方式。
    • 缺点： 需要修改源码（加DISPLAY语句），调试完后需记得删除或注释掉。大量输出可能影响性能（尤其是在循环中）。
  • 交互式调试器：
    • 优点： 功能强大，无需修改源码，可动态观察和干预，定位问题极其精确。
    • 缺点： 依赖于特定开发环境，学习有一定成本。对于在大型机生产环境上运行的程序，直接使用交互调试可能受限或风险较高。

注意事项：

  1. 安全第一： 在生产环境或连接生产数据的测试环境调试时，避免使用会修改数据的调试代码。最好在备份的、脱敏的数据上进行。
  2. 清理调试代码： 调试完成后，务必清理掉临时加入的DISPLAY语句或测试代码。可以在调试时使用*>DEBUG这样的注释前缀，方便后续用查找功能批量处理。
  3. 理解数据格式： COBOL中各种数据格式（COMP、COMP-3、PIC字符串）在内存中的存储和显示方式不同。确保你的DISPLAY语句能正确显示数值，特别是带符号的压缩十进制数（COMP-3），直接DISPLAY可能会看到乱码，可能需要先移动到一个显示字段。
  4. 利用COPYBOOK： 文件记录和数据库记录的布局通常定义在COPYBOOK里。调试时手边一定要有相关的COPYBOOK，它是你理解数据结构的“地图”。

文章总结： 调试复杂的COBOL业务逻辑，是一场与细节和耐心的较量。其核心思想是 “化整为零，步步为营” 。不要试图一口吃成胖子。从了解业务和现象开始，用DISPLAY语句进行战略性的“日志埋点”，像侦探一样梳理出程序的执行脉络和关键数据的变化轨迹。当问题被缩小到局部后，再善用调试器的精密工具进行定点勘察。最后，永远别忘了最朴素的“分解验证”思维，把大问题拆解成一个个可以独立验证的小单元。掌握这套组合拳，再复杂的COBOL逻辑迷宫，你也能找到出口。记住，好的调试不是碰运气，而是有策略的探索。你的代码不会说谎，只是需要你用正确的方式去提问。