遗留大型机现代化

您的 COBOL 仍在支撑 95% 的 ATM 交易。 而编写它的开发者们正在退休。

70-80% 的大型机现代化项目以失败告终。问题不在于技术本身,而在于工具将代码视为文本而非拓扑结构。我们在动一行代码之前先绘制出您代码库的全景图,让您的迁移在别人耗费数百万却一无所获之处取得成功。

1.52 万亿美元

美国技术债务

Pragmatic Coders,2025 年

10%/年

COBOL 人力流失率

IEEE Spectrum,2025 年

70-80%

现代化失败率

行业元分析,2025 年

为何 AI 代码翻译在大型机上失败

那些承诺“粘贴 COBOL,得到 Java”的工具生成的代码确实能编译。这只是简单的部分。困难的部分在于它们看不到的代码。

REDEFINES 难题:一个真实的迁移失败模式

设想一个电汇处理程序。它包含一条使用名为 TRN-LIMIT的变量的 COMPUTE 语句。一个 AI 编码助手将该语句翻译成 Java 的 BigDecimal 运算。代码通过编译。单元测试通过。

在 UAT 阶段,第一笔交易就让数据库一致性检查崩溃了。

事后剖析: TRN-LIMIT 并未定义在 AI 所翻译的源文件中。它定义在一个 copybook 里,而该 copybook 在执行链上数千行之前就被引入了。那个 copybook 包含一个 REDEFINES 子句——这是一种 COBOL 结构,它允许同一个内存地址根据在另一个完全不同的模块中设置的标志位,被解释为两种不同的数据类型。

AI 将 TRN-LIMIT 视为一个简单的数值字段,并假定它是标准整数类型。而在大型机上,那个内存地址保存的是压缩十进制数(COMP-3)。该 Java 应用程序将损坏的二进制数据写入数据库列,触发了引用完整性失败。

代码在语法上完美无缺。失败源于上下文盲区。AI 遗漏了一个存在于其视野之外的依赖关系。

隐藏依赖

Copybook 链

单个 COBOL 程序可能引用 40 多个 copybook。每个 copybook 又可能 COPY 其他 copybook。变量定义可能嵌套在引入链中 5 层之深。基于文本的 AI 工具对此一无所见。

不可见层

JCL 作业网络

您的 COBOL 并非独立运行。CA-7 或 TWS 调度着 2,000 至 5,000 个带有依赖链的 JCL 作业。作业 A 写入一个数据集,作业 B 在凌晨 2 点读取它。迁移了 COBOL 却漏掉了 JCL,生产环境就会在午夜崩溃。

算术陷阱

压缩十进制运算

COBOL 的 COMP-3 压缩十进制数在 Java 中没有对应类型。Java 的 double 会引入浮点舍入误差。即便是 BigDecimal ,也需要显式配置舍入模式(HALF_EVEN)才能匹配 COBOL 的 ROUNDED 子句。一分钱的差错会在数百万笔交易中累积放大。

2026 年的现代化格局

如今每一家主要技术供应商都在销售大型机现代化方案。以下是各家实际交付的内容,以及尚存的差距所在。

供应商 / 方法 其作用 典型成本 其遗漏之处
IBM Watsonx Code Assistant for Z 结合 ADDI 依赖分析的智能体式 COBOL 到 Java 翻译。多智能体架构(Orchestrate、Architect、Code 智能体)。支持 PL/I 和 IMS。 200 万美元以上(企业级许可 + z/OS 要求) ADDI 运行于 z/OS 之上,在迁移过程中造成供应商锁定。解析器难以处理 COBOL-85 标准之前的旧式结构(ALTER 语句)。无行为等价性测试。无 JCL 依赖映射。
Anthropic Claude Code AI 驱动的代码分析、文档生成、依赖映射。在发现与探索阶段表现出色。支持增量迁移和 API 封装。 基于用量的 API 定价 通用型 AI。无内置知识图谱用于传递性依赖解析。不涉及 JCL 调度、行为等价性测试或监管审计线索。
Microsoft Azure Migration Factory 通过 Semantic Kernel 实现的模块化智能体。COBOL 专家 + Java 专家智能体。目标为 Java Quarkus。Azure Copilot 迁移智能体处于预览阶段。 Azure 消费量 + 咨询费用 目标平台被 Azure 锁定。开源智能体是参考实现,并非可用于受监管环境的生产级方案。CICS/IMS 支持有限。
DXC Technology 已获专利的自动代码转换(COBOL/RPG/JCL 转 Java)。数十年的大型机专业经验。混合云 + 大型机即服务模式。 100 万至 1,000 万美元以上 专有工具,转换逻辑透明度有限。聚焦大型企业。18-36 个月的合作周期很常见。
TCS / Infosys / Accenture 拥有专有框架(MasterCraft、Cobalt)的大型系统集成商业务。庞大的交付团队。端到端项目管理。 50 万至 500 万美元以上 以平台为中心的方法。他们实施供应商工具,而非构建定制智能。大型 SI 合作模式带来高额开销。曾有一家 SI 主导某银行价值 10 亿澳元的迁移项目,历时 5 年、预算翻倍。
Micro Focus (OpenText) Visual COBOL 在 .NET/JVM 上原生运行 COBOL。务实的“绞杀者无花果”起步方案。COBOL 编译器市场领导者。 20 万至 50 万美元许可费 这不是现代化,而是重新托管。COBOL 逻辑仍然是 COBOL。技术债务依旧存在。无法解决人力问题。
使用开源 AI 自行实施 XMainframe LLM(7B/10.5B 参数,在 COBOL 上比 DeepSeek 强 30%)。Tree-sitter 解析。定制流水线。 工程时间 + 基础设施 需要深厚的 COBOL + 图工程专业能力。没有任何生产级 COBOL 解析器能覆盖所有 IBM Enterprise COBOL v6.x 结构。将解析器缺口构建进基础之中的风险很高。
诚实的告诫: 没有任何工具——包括我们的工具——能够解决组织内部的认同问题、数据质量问题,或说服 200 名开发者改变工作方式这一政治难题。技术是必要的,但并不充分。如果您的组织缺乏高层对现代化的支持,请先从这里着手,然后再接触任何供应商。

我们构建什么

五项能力,每一项都针对现代化工具链中的一个具体差距。我们保持供应商中立:无论您的目标是 AWS、Azure、GCP 还是本地部署的 Java,知识图谱都能发挥作用。

代码库知识图谱

我们将您的 COBOL 源代码、copybook、JCL 库、DB2 目录导出、CICS 事务定义和 IMS 段层次结构摄取到一个统一的图数据库中。每一个变量、每一条 PERFORM 链、每一个 REDEFINES 子句、每一项批处理依赖都成为图中一条显式的边。当复杂的传递闭包查询主导使用场景时,我们选用 Neo4j;当实时遍历速度对交互式探索至关重要时,我们选用 Memgraph。

在摄取期间,图每天大约处理 20 万至 30 万行代码。对于一个 200 万行代码的代码库,从首次摄取到经过验证、可查询的图,预计需要 8 至 12 周。其产出是一项永久性资产:您的代码库化为可搜索的拓扑结构,而非晦涩的文本文件。

迁移风险评估与提取排序

在任何代码翻译开始之前,我们会沿四个维度运行图分析:耦合度评分(有多少其他模块依赖于该模块)、REDEFINES/COMP-3 密度(存在多少数据类型陷阱)、死代码百分比(通常占代码库的 20-30%),以及批处理调度关键性(哪些 JCL 作业会触及该模块,以及何时触及)。

其产出是一份用于绞杀者无花果迁移的排序提取序列。耦合度最低、数据类型最简单的模块最先提取。被 50 多个其他模块调用的“上帝程序”最后提取。这一排序,正是受控推进与连锁故障之间的分水岭。

图增强的代码翻译

我们的翻译智能体在生成每个 Java 模块之前都会查询知识图谱,提取依赖关系的完整传递闭包。智能体能看到三个目录之外的 copybook 中的 REDEFINES 子句。它能看到决定舍入行为的压缩十进制定义。它生成的 Java 使用显式参数传递(依赖注入),而非 COBOL 的隐式全局状态。然后它在沙箱中编译、运行行为等价性测试并自我纠正。

我们会根据模块的复杂度选用最合适的基础模型。对于直接的 PERFORM 到方法的转换,较小的模型就够用了。对于含有嵌套 REDEFINES、需要展平控制流的 GOTO 意大利面式代码,或 EXEC CICS 嵌入式事务逻辑的模块,我们会引入现有最强大的模型,并用完整的图上下文对其进行增强。

行为等价性测试框架

这是大多数供应商跳过、而大多数迁移在此栽跟头的部分。我们构建一套三层验证系统:从图衍生的控制流路径生成的符号化单元测试;使用捕获的生产交易进行黄金数据集回放,逐字段以分文不差的精度进行比对;以及并行生产运行——在大型机模块退役之前,两个系统对实时交易并行处理 30 至 90 天。

金融计算需要使用带 HALF_EVEN 舍入模式的 BigDecimal,以匹配 COBOL 的 ROUNDED 子句。日期计算需要处理 COBOL 的 6 位日期格式(YYMMDD),并采用世纪窗口逻辑。我们将这些转换规则构建进测试框架,而非构建为质检过程中临时发现的零散补丁。

批处理调度迁移

我们将您的 JCL 作业网络、CA-7/TWS/Control-M 依赖链以及批处理序列解析进知识图谱。每个 JCL 作业都成为一个节点,并通过边连接到它所执行的 COBOL 程序、它所读写的数据集,以及它所依赖的调度条件(时间触发、数据集可用性、前置作业完成)。

当一个 COBOL 模块迁移到 Java 时,我们会同步在您的目标编排平台(Apache Airflow、AWS Step Functions、Azure Data Factory,或分布式环境下的 Control-M)中构建等价的调度。依赖链得以保留,并与原始的 CA-7/TWS 定义进行核验。一家典型的中型银行有 2,000 至 5,000 个 JCL 作业。这些情况我们都见过。

知识图谱如何解析一条 REDEFINES 链

逐步演示基于图的依赖解析如何防范最常见的迁移失败模式。

1

解析器摄取源代码与 Copybook

解析器处理 PROG-WIRE-01.cbl,遇到 COPY CB-ACCT-LIMITS,并顺着引入链继续。它为每一个变量声明构建 AST 节点,包括那些嵌套在 copybook 中 3 层之深的声明。

* 在 CB-ACCT-LIMITS.cpy 中:
01 ACCT-LIMIT-RECORD.
05 TRN-LIMIT PIC S9(9)V99 COMP-3.
05 TRN-LIMIT-ALPHA REDEFINES TRN-LIMIT PIC X(6).
05 LIMIT-TYPE-FLAG PIC X.
2

图创建关系边

图引擎创建边: PROG-WIRE-01 → IMPORTS → CB-ACCT-LIMITSTRN-LIMIT → REDEFINES → TRN-LIMIT-ALPHALIMIT-TYPE-FLAG → CONTROLS_TYPE_OF → TRN-LIMIT。这捕捉到了一个事实: TRN-LIMIT 的数据类型取决于另一个字段中的运行时标志位。

3

传递闭包揭示完整影响

图向外遍历:还有哪些其他程序也 COPY 了 CB-ACCT-LIMITS?哪些程序设置了 LIMIT-TYPE-FLAG?哪些 JCL 作业执行了这些程序,以及按什么顺序执行?其结果是一条完整的影响链。改变 TRN-LIMIT 的翻译方式,会影响这条链中的每一个程序。

4

翻译智能体获得完整上下文

当翻译智能体处理 PROG-WIRE-01时,GraphRAG 不仅检索源文件,还检索 copybook 定义、REDEFINES 关系、标志字段,以及所有设置该标志的程序。智能体生成一个采用类型安全联合模式的 Java 类:一个 TransactionLimit 对象,它在将底层字节解释为 BigDecimal (压缩十进制模式)或 String (字母模式)之前先检查标志位。

没有图: AI 假定 TRN-LIMIT 是一个简单的数值字段,在 Java 中生成一个 long ,于是第一笔电汇就损坏了数据库。 有了图: AI 看到完整的依赖链,并生成能正确处理两种解释的类型安全代码。这正是一次在 UAT 中能跑通的迁移与一次在生产环境中能跑通的迁移之间的区别。

我们的工作方式

四个阶段,每个阶段都有明确的交付物。我们不会报一个 3 年的时间表然后销声匿迹。每个阶段都会产出归您所有、可独立使用的成果。

阶段 1 / 4-6 周

评估与发现

  • 从 z/OS 导出源代码(COBOL、JCL、copybook、DB2 DDL)
  • COBOL 方言识别(IBM Enterprise v4/v5/v6、Micro Focus、Fujitsu)
  • 死代码扫描(典型结果:20-30% 的代码行不可达)
  • 按程序进行 MIPS 消耗分析
  • 带耦合度评分的初步提取序列

交付物:评估报告 + 初步知识图谱原型

阶段 2 / 8-12 周

知识图谱构建

  • 使用针对您方言的定制解析器扩展,进行完整代码库摄取
  • 跨所有 copybook、DB2 模式、CICS 定义的实体解析
  • 带 CA-7/TWS 依赖链的 JCL 作业网络映射
  • 带完整性验证的传递闭包计算
  • 交互式查询接口(“如果我改动这个变量会破坏什么?”)

交付物:可查询的知识图谱 + 排序的提取序列 + 影响分析工具

阶段 3 / 持续进行(绞杀者无花果)

增量迁移

  • 按提取序列逐个模块进行翻译
  • 带完整依赖上下文的图增强 AI 翻译
  • 逐模块的行为等价性测试(黄金数据集 + 并行运行)
  • 为每个已提取的模块进行批处理调度迁移
  • MIPS 降幅跟踪(典型:第 1 年降低 20-30%)

交付物:投入生产的已迁移 Java 模块 + 更新后的知识图谱 + 调度等价实现

阶段 4 / 逐模块进行

验证与退役

  • 每个模块 30-90 天的并行生产运行
  • 带分文不差金融验证的差异化输出比对
  • 监管文档(审计线索、变更控制、SOC 2 证据)
  • 签署确认后退役大型机模块
  • 更新知识图谱以反映新架构

交付物:经过验证的生产部署 + 监管文档包 + 更新后的图

时间表告诫: 这些是中型机构(100 万至 500 万行代码)的典型区间。更大的代码库、多种 COBOL 方言或大量使用 CICS 都会延长阶段 2。我们会在阶段 1 评估之后精确界定范围。

大型机现代化就绪度评估

回答关于您环境的七个问题。该评估将识别出您的就绪程度,以及在启动迁移合作之前需要解决的具体障碍——无论是否与 Veriprajna 合作。

1. 当前生产环境中有多少行 COBOL 代码在运行?

2. 您的环境使用哪种 COBOL 方言?

3. 您是否拥有关于批处理作业依赖关系的最新文档?

4. 您目前雇用了多少名具备 COBOL 技能的开发者?

5. 哪些监管框架适用于您的大型机系统?

6. 您此前是否尝试过现代化项目?

7. 董事会或高管层是否积极支持现代化?

CTO 与工程副总裁常向我们提出的问题

为一个 200 万行的 COBOL 代码库构建知识图谱需要多长时间?

对于一个具有典型复杂度的 200 万行代码的代码库(IBM Enterprise COBOL v6.x、DB2 嵌入式 SQL、500 多个 copybook),图构建需要 8 至 12 周。前 3 周用于解析器配置与验证。COBOL 方言差异之大,使我们在摄取整个代码库之前,需要核实解析器能够处理您对 REDEFINES、OCCURS DEPENDING ON 以及 EXEC CICS/SQL 块的特定用法。

第 4 至 8 周是自动化摄取、实体提取与关系映射。解析器每天大约处理 20 万至 30 万行,但瓶颈在于实体解析——具体而言,就是确定程序 A 中的 ACCT-NUM 与 copybook CB-ACCT-01 中的 ACCT-NUM 是同一个变量。

第 9 至 12 周是传递闭包计算与验证。我们运行图完整性检查:每一个 PERFORM 目标都必须解析到一个段落,每一条 COPY 语句都必须解析到一个 copybook,每一处 DB2 表引用都必须映射到一个模式定义。缺口会被标记出来供人工审查。其产出是一个可查询的知识图谱,您可以在其中提出诸如“如果我改动 CB-GLOBAL-01 中的 INTEREST-RATE 会发生什么?”这样的问题,并获得一条横跨每个直接或传递引用它的程序的完整影响链。

我们能否增量式现代化,而不是做彻底重写?

可以,而且我们强烈推荐这样做。绞杀者无花果模式是唯一在大型机迁移上有着可靠成功记录的方法。彻底重写有 70-80% 的失败率,因为它们试图同时替换一切,从而制造出一个庞大的单点故障。

采用绞杀者无花果方法时,知识图谱会识别出哪些模块的耦合度评分最低——也就是来自其他模块的入向依赖最少。这些就是您的提取候选模块。我们通常从批处理报表模块或独立的计算例程开始,这些模块从 DB2 读取数据但不更新共享状态。新的 Java 服务与大型机并行运行。针对该特定功能的生产流量被路由到新服务,而大型机继续处理其他一切。在退役 COBOL 模块之前,您要在真实生产数据上验证行为等价性。

大多数组织在第一年提取 15 至 20 个模块,将 MIPS 消耗降低 20-30%,并产生足够的成本节约来为下一阶段提供资金。知识图谱让这一切变得安全,因为它会向您展示每次提取的影响范围。如果模块 A 被另外 47 个程序调用,那它就不是您的首个提取候选。如果模块 B 仅被 2 个程序调用且只从 1 张 DB2 表读取,那就从它开始。

对于大多数 AI 工具都忽视的 JCL 批处理依赖,你们如何处理?

这正是大多数现代化项目在进行 6 到 12 个月后遭遇意外故障的那一层。您的 COBOL 程序并非孤立运行。它们由 CA-7、TWS(Tivoli Workload Scheduler)或 Control-M 所管理的 JCL 作业流编排。一家典型的中型银行有 2,000 至 5,000 个 JCL 作业,带有复杂的依赖链:作业 A 必须在作业 B 启动之前完成,作业 C 仅在每月最后一个工作日运行,作业 D 触发一个 CICS 事务,该事务更新一个由作业 E 读取的 VSAM 文件。

我们将 JCL 与 COBOL 一并解析进同一个知识图谱。每个 JCL 作业都成为一个节点,并通过边连接到它所执行的 COBOL 程序、它所读写的数据集,以及它所依赖的调度条件。当我们将一个 COBOL 模块迁移到 Java 时,我们会同步在您的目标平台中构建等价的调度,无论那是 Apache Airflow、AWS Step Functions 还是 Azure Data Factory。依赖链得以保留,并与原始定义进行核验。

我们见过这样的项目:代码迁移完美成功,但生产环境却崩溃了,原因是没有人映射出那个每晚凌晨 2 点运行某预处理步骤的 CA-7 作业。

你们的方法与 IBM Watsonx Code Assistant for Z 有何不同?

IBM Watsonx Code Assistant for Z(当前版本为 v2.8.20,Project Bob 将于 2026 年晚些时候推出)是一款功能强大、与大型机深度集成的产品。它需要 IBM ADDI(应用发现与交付智能)来构建其依赖分析,而 ADDI 运行于 z/OS 之上。这意味着您的依赖分析工具就驻留在您正试图迁离的那台大型机上。这也意味着 IBM 掌控着分析层,从而在迁移最关键的阶段造成供应商锁定。

我们的知识图谱在大型机之外运行。我们摄取源代码导出、JCL 库、DB2 目录导出和 copybook 仓库。该图驻留在您的云环境或本地基础设施中,独立于 IBM 许可。其次,Watsonx 专注于 COBOL 到 Java 的翻译。我们则先专注于理解,再进行翻译。知识图谱是一项永久性资产,在迁移完成后很久仍能服务于影响分析、文档生成和架构治理。

第三,ADDI 的 COBOL 解析器在处理 COBOL-85 标准之前的旧式 COBOL 结构方面存在已记录的局限,尤其是 ALTER 语句和某些嵌套 REDEFINES 模式。我们为每个客户的方言构建定制的解析器扩展。

最后,IBM 的定价面向大型企业。我们的合作模式适用于中型机构——对它们而言,200 万美元以上的 IBM 合作并不在预算之内。

你们如何证明 Java 代码的行为与 COBOL 原始代码完全一致?

行为等价性正是大多数 AI 辅助迁移功亏一篑的地方。能够编译并通过单元测试的代码,仍可能因压缩十进制舍入差异、EBCDIC 到 ASCII 的编码不匹配,或无法转换为 Java 对象的 REDEFINES 内存覆盖语义,而产生错误结果。

我们构建一套三层验证框架。第 1 层是符号等价性:我们从知识图谱生成单元测试,覆盖原始 COBOL 控制流中的每一个分支,包括负数金额、除零防护和闰年日期计算等边界情况。第 2 层是黄金数据集回放:我们从大型机捕获一组有代表性的生产交易(输入记录、DB2 读取、CICS 交互),并通过新的 Java 服务重放它们。输出逐字段进行比对。对于金融计算,我们使用带 HALF_EVEN 舍入的 BigDecimal 验证分文不差的精度,以匹配 COBOL 的 ROUNDED 子句行为。

第 3 层是并行生产运行:两个系统对相同的实时交易同时处理 30 至 90 天。差异会被记录、调查并修复,然后才退役大型机模块。这是耗时最长的阶段,但也正是这一阶段能够捕捉到那些在 30 年生产中累积下来、任何测试套件都无法完全预料的边界情况。

DORA 对我们的大型机系统意味着什么,现代化对合规是否有帮助?

DORA(《数字运营韧性法案》)自 2025 年 1 月 17 日起已全面生效,它直接影响任何运行大型机系统的受欧盟监管金融实体。第 11 条要求建立 ICT 风险管理框架,其中包括定期韧性测试和基于真实世界攻击场景的、由威胁主导的渗透测试。大多数大型机环境并非为此类测试而设计。您无法在不承担巨额许可和基础设施成本的情况下,轻易搭建一个 z/OS 副本环境来运行渗透测试。

DORA 还要求详尽的 ICT 资产清单、在特定时限内的事件报告,以及针对关键 ICT 服务提供商(其中包括您的大型机供应商)的第三方风险管理。现代化在两个方面提供帮助。首先,知识图谱本身就充当了 DORA 所要求的 ICT 资产清单。它映射了每一个程序、每一条数据流、每一项外部依赖。监管机构可以直接查询它。

其次,运行在云基础设施上的已迁移组件本质上更易于进行韧性测试。您可以按需搭建测试环境、运行混沌工程场景,并在不影响生产的情况下验证恢复流程。我们见过一些机构在监管检查中将知识图谱用作证据,以证明它们了解自身的技术资产版图——甚至在迁移完成之前就能做到。

技术研究

本解决方案页面背后的方法论,植根于我们就遗留系统现代化与知识图谱架构所发表的研究。

理解的架构:在企业遗留现代化中超越语法

仓库感知的知识图谱与 GraphRAG 如何克服导致 AI 代码翻译在企业 COBOL 系统上失败的“中段迷失”综合症。

您的大型机每个 MIPS 每年花费 1,000 至 2,000 美元。我们能精确绘制出应当首先消除哪些 MIPS。

对于一家中型机构,第 1 年 20-30% 的 MIPS 降幅通常每年可节省 50 万至 200 万美元。

知识图谱评估需要 4-6 周。无论您是否继续进行迁移,您都将获得一份完整的代码库依赖图、一份死代码报告,以及一份排序的提取序列。该评估本身就是一项永久性资产。

代码库评估

  • ✓ 您 COBOL 资产的知识图谱原型
  • ✓ 死代码识别(通常占代码行的 20-30%)
  • ✓ 按程序进行的 MIPS 消耗分析
  • ✓ 带耦合度评分的排序模块提取序列

完整迁移合作

  • ✓ 覆盖 JCL/DB2/CICS 的完整知识图谱
  • ✓ 通过绞杀者无花果模式进行增量迁移
  • ✓ 逐模块的行为等价性测试
  • ✓ 监管文档与审计线索