历经 20 年打磨，GnuCOBOL 已准备好投入工业使用

GnuCOBOL 的成熟度与标准符合性

• 之所以被认为“已准备好”，主要是因为其稳定性和对 COBOL‑85 的高符合度（约 97% 的测试通过）。
• 评论者指出，即使是许多专有 COBOL 实现也从未达到完全符合标准。
• 采用 GNU MP 进行算术运算，以匹配传统 COBOL 固定精度行为，而不是 IEEE‑754 浮点。
• 缺少较新 COBOL 标准中的功能，例如对象和消息传递（如 COBOL 2022/2023）。

COBOL 在当前系统中的角色

• 生产环境中的 COBOL 大多运行在 IBM 大型机上，并与 JCL、数据库（DB2、IMS、DMS）以及事务监控器（CICS、ACMS）紧密耦合。
• 在非 IBM 平台上也很常见：OpenVMS、OS2200、各种 Unix 变体，以及 x86/Linux 上的 Micro Focus 等厂商方案。
• 广泛用于金融、工资、计费、ERP，以及其他“无聊但关键”的后台工作负载。

大型机 vs 云与可靠性

• 大型机被描述为按“五个九”的可用性设计，具有极端冗余和极少的停机时间。
• 银行经历的故障常被归咎于周边服务器基础设施，而不是大型机核心。
• 云的“五个九”被批评为更多只是计费/赔偿 SLA，而不是真正的持续不停机运行。
• 也有人表示实际使用中的一些大型机环境很脆弱，因此可靠性说法并不适用于所有情况。

迁移、生态系统与 JCL

• GnuCOBOL 被视为只完成了迁移故事的一半：你仍然需要 JCL、类似 CICS 的事务监控，以及大型机风格的数据库。
• JCL 被认为对批处理至关重要；REXX 常用于生成 JCL，而不是取代它。
• 许多迁移尝试（包括 COBOL 到 C 的逐字转写）被描述为痛苦，或最终变成难以维护的系统。
• COBOL 系统失败后一次次被重写、却又无休止重复失败的现代化尝试，被认为是一种常见模式。

数值正确性与“金钱计算”

• COBOL 的十进制算术和固定精度对金融系统至关重要。
• 迁移到默认使用二进制浮点的语言很有风险；虽然存在正确的等价实现（如 BigDecimal 等），但它们不符合惯用风格，而且可能较慢。
• 这种数学行为是组织不愿放弃 COBOL 的主要原因之一。

语言特性与开发者体验

• COBOL 冗长且以数据定义为中心，但许多人认为它在其目标领域中很直接。
• 强静态的数据布局（PICTURE 子句）可避免缓冲区溢出和内存破坏；内存是显式定义的，而不是动态分配的。
• 难点更多不在语法，而在领域复杂性和大型机工具链。
• 仍然存在持续的新 COBOL 开发，尽管较为小众，通常是更大型 ERP 或遗留平台的一部分。

为什么遗留 COBOL 仍在延续

• 核心会计、工资和金融规则变化缓慢；现有系统承载了数十年的立法、工会协议和边缘案例。
• 往往没有完整的当前需求文档，运行中的代码本身就是规格说明。
• 在 COBOL 上做增量修改比彻底重写更便宜、风险更低，尤其是在没人能完全理解全部业务逻辑时。
• 许多“旧”系统其实是忒修斯之船：在时间中被大量修改，但从未被根本替换。

采用前景与怀疑态度

• 对 GnuCOBOL 作为免费、面向标准的编译器以及潜在迁移工具抱有热情。
• 也有人怀疑大型大型机团队会因监管约束、生态锁定和风险厌恶而转移平台。
• 一些人怀疑今天还有多少新项目会选择 COBOL；大多数人预计它仍将是维护和增量变更语言。