一、为什么要盯着大型机上的COBOL程序

1.1 那些跑在大型机上的COBOL程序

很多人可能没听过COBOL，它就是那种看起来像“老古董”但在银行、保险、证券里用到死的编程语言，而承载它的大型机，就像个能扛住海量数据的老金库。比如你每月收到的工资代发、社保的批量缴费、股票的清算对账，大概率都是COBOL程序在大型机上跑出来的。这些程序从十几年前用到现在，中间换了好几轮新系统，但没人敢随便替换，因为它太稳定了，就像开了几十年的老出租车，从来没掉过链子。

1.2 不监控会出什么问题

去年我接触过一个银行的项目，他们的COBOL代发程序本来计划1小时跑完当月的工资，结果跑了4小时，导致上千名员工到下午还没收到钱，投诉电话直接打爆了客服中心。后来排查才发现，程序里的一个循环没做优化，每次都全表扫描员工数据，数据量变大后直接拖垮了性能。要是提前做了监控，就能在跑批前发现这个问题，不会影响业务。

二、怎么给COBOL程序加简单的性能监控

2.1 用COBOL代码埋点记录时间

不用复杂的大型机监控工具，给COBOL程序加几行记录时间的代码，就能拿到性能数据。这里用COBOL（大型机平台）写了一个最简单的监控示例，全程都是针对程序核心耗时的埋点，还加了详细注释：

* 技术栈：COBOL（大型机平台，符合IBM z/OS语法规范）
IDENTIFICATION DIVISION.
PROGRAM-ID. SIMPLE-PERF-MONITOR.
AUTHOR. 一线运维开发.
DATE-WRITTEN. 2024-05-25.

ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. ZOS-MAINFRAME.
OBJECT-COMPUTER. ZOS-MAINFRAME.

DATA DIVISION.
WORKING-STORAGE SECTION.
* 存储程序开始执行的时间戳（单位：毫秒）
01 START-TIME        PIC 9(12) VALUE 0.
* 存储程序结束执行的时间戳
01 END-TIME          PIC 9(12) VALUE 0.
* 存储计算出来的总耗时
01 TOTAL-ELAPSED     PIC 9(8) VALUE 0.

PROCEDURE DIVISION.
MAIN-SECTION.
* 1. 记录程序启动的时间，调用大型机自带的时间工具
CALL 'ISHELL' USING 'DATE +%s%3d' RETURNING START-TIME.

* 2. 模拟核心业务逻辑（比如计算1000名员工的工资明细）
PERFORM 1000 TIMES
   ADD 1 TO SALARY-TOTAL  * 假装是计算员工工资的操作
END-PERFORM.

* 3. 记录程序结束的时间
CALL 'ISHELL' USING 'DATE +%s%3d' RETURNING END-TIME.

* 4. 计算总耗时，单位：毫秒
SUBTRACT START-TIME FROM END-TIME GIVING TOTAL-ELAPSED.

* 5. 把性能结果输出到大型机的默认日志（SYSOUT），方便查看
DISPLAY 'PERF_RESULT: TOTAL TIME = ' TOTAL-ELAPSED 'ms'
   UPON SYSOUT.

STOP RUN.

这个代码的核心就是埋了两个时间点，最后算出总耗时，所有输出都会存到SYSOUT日志里，不用额外的存储设备。

2.2 怎么快速查看监控结果

大型机上查SYSOUT日志很简单，用SDSF工具就能直接搜程序ID，找到刚才跑的SIMPLE-PERF-MONITOR程序的输出，最后一行就能看到总耗时。比如刚才的示例里，要是输出的是1500ms，说明整个程序只跑了1.5秒，要是跑了10秒，就可以标记为潜在的性能问题。

三、性能分析的核心步骤

3.1 先拆分程序找瓶颈点

刚才的示例是整个程序的总耗时，要是总耗时太长，就得把程序拆成几个模块，每个模块都加时间记录。比如代发程序可以拆成“读取员工数据”“计算工资”“写入银行系统”三个模块，每个模块都埋时间点，这样就能找到到底是读数据慢还是写数据慢，不用整个程序一起查。

3.2 用日志辅助排查细节

SYSOUT日志里除了耗时，还会记录IO操作的次数（就是读硬盘数据的次数），要是某个模块的IO次数特别多，比如每秒读了1万次，那肯定是程序的查询逻辑有问题，比如没加索引、每次都读全表，这些都是肉眼能从日志里直接看出来的，不用查复杂的后台数据。

四、这类监控方法的应用场景、优缺点和注意事项

4.1 常见应用场景

这种监控方法几乎覆盖了所有用COBOL的大型机业务，比如银行的批量代发、证券的每日清算、保险公司的保单核保、电商的月度对账，只要是需要批量跑数据的核心业务，都能用来监控性能，避免跑批超时影响业务。

4.2 技术优缺点

优点很明显：一是不用买昂贵的大型机监控工具，只需要改几行COBOL代码，适合预算有限的中小金融机构；二是监控数据直接和程序绑定，准确性高，不会被其他系统的干扰影响；三是监控代码本身的资源占用极低，几乎不会拖慢原程序。 缺点也很突出：一是COBOL语法非常严格，加监控代码的时候多写个句号、少写个空格，整个程序就跑不起来；二是现在会写COBOL的程序员越来越少，维护监控代码的人难找；三是大型机的存储空间有限，监控日志最多存一个月，得定期删除，不然会占用核心业务的存储资源。

4.3 必须注意的事项

第一，一定要先测再上生产。加了监控代码后，先在测试环境跑一遍，确认程序能正常执行，性能数据的误差在合理范围内，再放到生产环境，不然会影响核心业务；第二，性能指标要和业务方一起定，不能自己说了算，比如代发程序的耗时不能超过20分钟，得让银行的业务人员确认这个阈值，不然误判的话会白忙活；第三，每周至少抽10分钟看一次SYSOUT的性能日志，要是某个模块的耗时每周都增加，说明数据量变大了，得提前优化，不然下次跑批肯定超时；第四，不要给所有COBOL程序都加监控，只需要给核心批量程序加，不然会给运维增加额外的工作量。

五、总结

大型机上的COBOL程序是企业的“核心老伙计”，性能监控不是什么高大上的技术，就是为了提前发现问题，避免业务故障。用简单的代码埋点查看日志的方法，就能解决80%的性能问题，不用学复杂的大型机工具。只要养成定期看性能数据的习惯，就能让这些老伙计一直稳定跑下去，不用担心中途掉链子。