3. 函数和子程序调用机制极其混乱
在 COBOL 中，变量是按值传递或按引用传递并非由函数定义决定，而是由调用位置决定。这意味着，一个接受 4 个参数的函数，实际上可能有 16 种不同的调用方式。
函数调用时没有类型检查，甚至连参数大小都不验证。这就好比 JavaScript 或 PHP 的弱类型机制，但实际上更类似于 FORTH--调用者只是将数据填充到一段原始内存中，而被调用的函数则随意解释这段内存内容。如果调用者和被调用者的理解不一致，程序就会崩溃。
默认情况下，局部变量是持久化的，除非手动使用 CLEAR 语句清除状态，这意味着所有函数默认都是有状态的，并且数据全局可见。
4. 程序的控制流设计极其落后
GOTO 仍然广泛存在，令人堪忧。
PERFORM THRU 语句的存在，使得程序逻辑混乱不堪。
ALTER 语句允许动态修改代码逻辑，导致代码的可维护性极差。
5. COBOL 语言的动词设计极为复杂
COBOL 的核心动词（如 UNSTRING）的行为可能根据使用方式的不同而发生变化，且返回结果会直接修改变量，而不是通过返回值的方式处理。
由于 COBOL 语言本身缺乏良好的函数调用机制，因此大量复杂功能被塞进了动词系统中，导致解析和转换难度陡增。
6. COBOL 的数据结构设计混乱
尽管 PICTURE 句法的基本设计勉强可以接受（尤其是对十进制数的支持），但字符串处理方式已完全过时。
由于 COBOL 早期是基于字符串存储所有数据的，其复合类型（Group 数据项）非常原始，远远无法与现代编程语言的结构体或对象系统相比。
正因此，Lemon640 认为，「这一切仍然是一个巨大的技术债务问题--COBOL 代码本身的问题只是表象，真正最大的技术债务，是那些深埋在 COBOL 代码中的业务逻辑和知识体系，它们仍然难以访问、难以理解、难以变更。」
最后，尽管不少人推荐 IBM 早前推出的 watsonx Code Assistant for Z，这一生成式 AI 工具能够将 COBOL 代码重构为 Java，以加速 COBOL 应用现代化，但它仍只是整体解决方案的一部分。
同时，也有人设想马斯克可能会对 AI 说："Grok，我需要你非常努力，为我编写一个新的 SSA 系统。" 然而，现实是这样的任务远非几个月内能够完成，重写代码也绝非"发射火箭"那么快。
真正的现代化进程，仍依赖于技术积累、系统设计与长期优化的协同推进。
