COBOL 现代化智能

我们先绘制你代码库的地图,再动一行代码。

大多数现代化项目失败,是因为工具把代码当文本读,而不是当拓扑读。CodeGraph 将你的大型机资产解析为带类型的知识图谱,并解析一次变更的完整传递依赖闭包——跨越 copybook、REDEFINES、COMP-3、DB2 和 JCL,每条边都带 file:line 出处,并证明它能解析多少。地图即产品。转译是下游用例。

9/9 vs 3/9

已找回的依赖:图谱 vs 单文件窗口

在 TRN-LIMIT 夹具上,对照已知真值集

97.1%

引用已解析(33 of 34),1 处标记待复核

确定性完备性门禁,每次运行结果相同

47 / 70

覆盖 7 种节点类型的节点与边

随附交付的合成银行夹具

这是一份可运行的演示。资产为合成并专为本演示编写,图谱驻于内存加 SQLite,而 DB2、JCL 以及朴素单文件视图均为文件夹具与模拟,不是实时连接器。

现代化败在理解,而不是转译

失败模式是上下文盲视,更大的模型并不能消除它。

70 to 80% 的大型机现代化项目未能达成目标(行业元分析,2025)。不是因为转译出错,而是因为工具把代码当文本而非拓扑。通用转译器只读它能看见的那一个文件。真正要紧的事实,在单文件上下文窗口里是看不见的。

利害并非学术。约 220 billion 行 COBOL 仍在生产运行,承载约 95% 的 ATM 交易、43% 的银行系统,以及每天 3 trillion 美元的活动(Reuters, 2017),对照估计 1.52 trillion 美元的美国累计技术债(CISQ, 2022)。这是银行与保险技术栈的核心,也正是没人愿意盲目去动的代码。

具体寓言是一个在名为 TRN-LIMIT 的字段上做计算的电汇程序。在转译器能看见的那一个文件里,算术看起来微不足道。但 TRN-LIMIT 是三份 copybook 之外定义的 COMP-3 压缩十进制,其解释由另一个程序设置的标志决定,而该标志由凌晨 2 点、在电汇作业之前运行的 JCL 批处理作业写入。只拿到可见事实时,模型会发出一个普通 long,Java 能编译、能过单元测试,然后在第一次真实电汇时损坏数据库。该参照完整性失败会在 UAT 中浮现。失败就是上下文盲视。

这不会随着模型改进而过时。真实资产是 1 to 10 million 行或更多,塞不进任何上下文窗口,无论现在还是未来。难的是检索一次变更所触及的精确传递切片,并证明你找到了全部。那是拓扑、检索与证据问题,不是推理质量问题。智能体提供建议,代码作出决定。

CodeGraph 如何运作

将资产解析为带类型的图谱,然后运行确定性分析。关键路径上没有 LLM。

流水线依次运行:夹具资产,然后解析(COBOL、copybook、JCL、DB2 DDL),然后构建带类型的知识图谱,然后传递闭包影响加出处,然后确定性分析,然后审计与证据导出,然后交互式仪表盘。加载时应用通过 Server-Sent Events 实时运行,因此每一阶段都在控制台以真实测得延迟旁白,面板逐步填满,持久的阶段轨让你打开任一阶段的 Input、Processing 和 Output 追踪。单一控件可重放整次运行。

正在对 WIRETXN 程序运行实时分析流水线的 CodeGraph 界面,控制台显示各阶段延迟:扫描、解析、构建图谱、影响闭包、恢复事实,以及规划与审计。
实时流水线:扫描、解析、构建图谱、影响闭包、恢复事实,以及规划与审计,每一阶段都带真实测得延迟。

带类型的知识图谱

用 networkx 构建并驻于内存加 SQLite,图谱有七种节点类型(program、copybook、variable、table、jcl、dataset,以及 unresolved 占位)以及诸如 DEFINES、IMPORTS、REDEFINES、CONTROLS_TYPE_OF、WRITES_VAR、REFERENCES、CALLS、READS 和 WRITES、EXECUTES、USES_DATASET 和 PRECEDES 的带类型边。在随附夹具上,图谱有 47 个节点和 70 条边:14 个程序、5 份 copybook、17 个变量、3 张 DB2 表、3 个 JCL 作业、4 个数据集,以及 1 个未解析节点。

四项确定性分析

这些是普通图算法,不是模型调用,因此同一夹具每次运行给出相同结果。

1. 带出处的影响闭包

一次变更的传递依赖切片,每条边携带其 file:line 来源,因此你不仅能看见受影响的是什么,还能看见证据在哪里。

2. 朴素 vs 图谱召回

将图谱闭包对照夹具已知真值依赖集打分,对照模拟的单文件窗口——那才是基于文本的工具实际喂给模型的内容。

3. 抽取排序

每个程序的耦合与爆炸半径分数(耦合权重三、COMP-3 陷阱权重二、JCL 关键性权重二、未解析调用权重五),据此排出安全的绞杀藤迁移顺序。

4. 死代码可达性与完备性门禁

每一处 PERFORM、CALL、COPY 和 DB2 引用必须解析,或被标记为需复核,绝不能静默丢弃。不可达段落作为说明报告,不作为头条指标计分。

一个开关让差别可感知。勾选朴素 AI 上下文视图,图谱淡化为带少量上下文行的单一源文件。九项电汇事实中的六项消失,红色横幅陈述后果,翻回去则连同凭据恢复 9/9。该开关是检索层必须提供何种上下文的说明,不是价值来源。

完成后,Export JSON 写出 migration-evidence.json 文件,Evidence report 渲染可打印的代码库拓扑与完备性报告:节点与边摘要、带 file:line 出处的按模块闭包、召回结果与方法、排序后的抽取序列、死代码列表,以及时间戳。我们将其定位为 DORA ICT 资产清单和 SOC-2 变更控制凭证。可选的 Pydantic-AI 层可就闭包回答问题,但默认关闭且受密钥门控,确定性演示在没有任何密钥的情况下记录结果。

TRN-LIMIT 电汇闭包,端到端走通

对一个字段的一次变更,对照已知真值集解析。下方每张图都是运行中应用的截图。

九项事实,其中六项单文件看不见

默认视图落在电汇子系统,并选中 TRN-LIMIT。影响面板显示图谱检索为 9/9(100%),对照朴素单文件上下文的 3/9(33%),对照夹具已知真值依赖集打分。一个文件里可见三项事实:WIRETXN 在 COMPUTE 中使用 TRN-LIMIT(WIRETXN.cbl:33),按名称导入 copybook CBACCT(WIRETXN.cbl:13),以及对 DB2 表 ACCOUNTS 的 UPDATE(WIRETXN.cbl:37)。决定正确性的六项则不可见:TRN-LIMIT 是 PIC S9(9)V99 COMP-3 压缩十进制,必须成为 BigDecimal 而不是 long(CBACCT.cpy:11),TRN-LIMIT-ALPHA 将其 REDEFINES 为覆盖同一六字节的文本(CBACCT.cpy:12),LIMIT-TYPE-FLAG 决定哪种解释生效(CBACCT.cpy:13),两个程序(LIMITSET 和 BATCHUPD)写入该标志,而 02:00 的 JCL 作业 NIGHTLY 在 WIREJOB 之前运行,因此标志在电汇运行前已设置。

TRN-LIMIT 影响面板:图谱检索 9/9 vs 朴素单文件 3/9,事实 F1 至 F3 标为文件内,F4 至 F9 标为隐藏且 critical 或 high,每项都带 file:line 出处。
图谱检索 9/9 vs 朴素单文件 3/9。三项可见事实在文件内;决定类型的六项对单文件视图隐藏,每项都带 file:line 出处。

关键一击:切到单文件窗口,看六项事实消失

勾选朴素 AI 上下文视图,图谱淡化为 WIRETXN.cbl 内部所存。COMP-3 类型、REDEFINES 覆盖、控制标志、其两个跨模块写入者,以及 02:00 JCL 前驱全部变灰,红色横幅陈述后果:只拿到三项可见事实,模型发出普通 long 的 TRN_LIMIT,并把损坏字节写入 ACCOUNTS.TRN_LIMIT,这就是 UAT 失败。这正是文本窗口工具在结构上无法弥合的上下文盲视缺口,一键可见。

朴素单文件上下文视图:红色横幅说明只有 3 of 9 项事实位于 WIRETXN.cbl 内部,事实 F4 至 F9 被变灰,包括 COMP-3 类型、REDEFINES 覆盖、控制标志,以及 02:00 JCL 前驱。
朴素单文件视图:六项事实变暗,红色横幅陈述由此导致的生产失败。翻回去,9/9 连同凭据一并回来。

按爆炸半径排序的安全抽取顺序

抽取视图按耦合与爆炸半径分数对全部 14 个程序排序。AUDITLOG 是安全的首次抽取,rank 1,风险分数为 0,耦合为零。WIRETXN 位于 rank 11(risk 4,一个 COMP-3 陷阱加 JCL 关键性)。DISPATCH 为 rank 12(risk 5),因其未解析的动态 CALL,上帝程序 ACCTMGR 最后抽取,位于 rank 14(coupling 5,risk 15)。这是你可以辩护的绞杀藤顺序:最低风险优先,最高耦合最后。

按耦合、COMP-3 陷阱、JCL 关键性和风险分数对 14 个程序排序的抽取序列表,AUDITLOG 以 risk 0 居首,上帝程序 ACCTMGR 以 risk 15 居末,旁边是遗留到已现代化的 diff 视图。
绞杀藤顺序:AUDITLOG 以 risk 0 居首,ACCTMGR 以 risk 15 居末,各 rank 的原因显示在耦合、陷阱和 JCL 列中。

标记无法解析内容的完备性门禁

审计选项卡报告 97.1% 的引用已解析,即 33 of 34,恰好一处标记待复核而非静默丢弃。那一处是 DISPATCH 的动态 CALL WS-PROGNAME,其目标在运行时计算(DISPATCH.cbl:15),因此无法静态解析。该选项卡还按可达性列出死代码:AUDITLOG 的 LEGACY-FORMAT 段落和 WIRETXN 的 OLD-LIMIT-CHECK 段落不可达。拒绝伪造解析是诚实行为,也是监管方希望看到的行为。

显示 97.1% 引用已解析且 1 处标记待复核的审计选项卡,DISPATCH 的动态 CALL WS-PROGNAME 被标出为已标记而非静默丢弃,死代码列表点名 AUDITLOG LEGACY-FORMAT 和 WIRETXN OLD-LIMIT-CHECK。
97.1% 已解析,1 处已标记。无法解析的动态 CALL 被标为待复核,而非丢弃,死代码列表一并报告。

可导出的审计产物

以上全部导出为可打印的代码库拓扑与完备性报告:47 节点、70 边摘要,97.1% 覆盖率,九项带单文件可见性与 file:line 出处的 TRN-LIMIT 依赖事实,排序后的抽取序列,以及生成时间戳。因为资产为合成并经编写,真实依赖集由构造已知,这才使召回数字成为可复现的带标签测量,而不是一项声称。我们将 9/9、3/9 和 97.1% 归于这份随附夹具,从不作为对任意 COBOL 资产的开放世界保证。

可打印的代码库拓扑与完备性报告,显示 47 个节点、70 条边、97.1% 引用已解析、带单文件可见性与出处的 TRN-LIMIT 依赖事实 F1 至 F9,以及绞杀藤抽取序列。
可导出的代码库拓扑与完备性报告:节点与边摘要、带出处的九项依赖事实,以及排序后的抽取序列,定位为 DORA ICT 资产清单。

单文件上下文窗口 vs 图谱

演示对照的同一开关,并排展示于电汇夹具。

维度 单文件上下文窗口 CodeGraph 知识图谱
已找回的 TRN-LIMIT 依赖 3 of 9 9 of 9,对照已知真值集
跨越 copybook 的 COMP-3 类型 不可见 已解析,带 file:line 出处
REDEFINES 覆盖与控制标志 不可见 已解析,包括跨模块写入者
仅 JCL 的排序边(NIGHTLY 在 WIREJOB 之前) 不可见 建模为 PRECEDES 边
完备性证明 97.1% 已解析,未解析者标记待复核
安全抽取顺序 按耦合与爆炸半径排序
审计产物 可导出的拓扑与完备性报告

本演示不会做的事

  • ✓ 它不把 COBOL 转译为 Java。CodeGraph 是理解层,即地图。转译是它刻意不去执行的下游用例。
  • ✓ 它不使用实时连接器。图谱驻于内存加 SQLite,DB2、JCL 和调度器输入是文件夹具,朴素单文件视图是模拟的上下文窗口。Neo4j 或 Memgraph 是点名的生产路径,不在此处交付。
  • ✓ 它不把该银行、其程序或任何数字呈现为真实客户的代码库。资产为合成并专为本演示编写。没有案例研究,也没有部署结果。
  • ✓ 它不声称覆盖全部 IBM Enterprise COBOL 方言。解析器覆盖现实的合成子集,而非每一种方言、ALTER 或 OCCURS DEPENDING ON,也不声称胜过任何厂商的解析器。
  • ✓ 它不把 9/9、3/9 或 97.1% 呈现为开放世界保证。它们是对随附合成电汇夹具的测量,其真值集由构造已知。
  • ✓ 它不携带客户、案例研究、证言或 ROI 数字。目前都不存在。这是一份证明机制的演示。

买家真正会问的问题

这是 COBOL 到 Java 的转译器吗?

不是。CodeGraph 是理解层,不是转译器,它刻意不去粘贴 COBOL 再输出 Java。它为你的资产构建带类型的依赖图谱,并解析一次变更所触及的精确传递切片,带 file:line 出处和完备性证明。转译是下游用例,而每一种转译工具仍需要这张地图,才能知道一次变更实际触及什么。

更大的上下文窗口或更好的模型不就能解决这个问题吗?

不能,而这正是耐久的要点。真实资产是 1 to 10 million 行或更多,塞不进任何上下文窗口,无论现在还是未来。难的是检索精确传递切片并证明你找到了全部,这是拓扑、检索与证据问题,不是推理质量问题。完美的模型仍然无法向监管方证明检索到了哪些依赖,仍然需要安全的抽取顺序,仍然欠一份 ICT 资产清单。

你如何向审计员证明找到了每一项依赖?

完备性门禁要求每一处 PERFORM、CALL、COPY 和 DB2 引用要么解析,要么标记待复核,绝不能静默丢弃。在随附夹具上,那是 33 of 34 处引用已解析,即 97.1% 覆盖率,无法解析的那一处被标记。你可以导出可打印的代码库拓扑与完备性报告,含节点与边摘要、带 file:line 出处的按模块闭包、召回结果与方法、排序后的抽取序列,以及死代码列表,定位为 DORA ICT 资产清单和 SOC-2 变更控制凭证。

遇到无法解析的依赖,例如动态 CALL,会怎样?

它被标记待复核,而不是静默丢弃,这种诚实行为才是要点。在夹具上,无法解析的那一处引用是 DISPATCH 的动态 CALL WS-PROGNAME,其目标在运行时计算(DISPATCH.cbl:15),因此无法静态解析。CodeGraph 将其记录为需复核,并正因为这一原因将 DISPATCH 排在安全抽取顺序的近末位。

这会连接到我们的大型机、DB2 或 z/OS 调度器吗?

在本演示中不会。图谱驻于内存加 SQLite,DB2、JCL 和调度器输入是文件夹具,而朴素单文件视图是模拟的上下文窗口。生产部署会点名 Neo4j 或 Memgraph 这类图谱平台并读取你的真实资产,但此处没有任何内容暗示实时 z/OS 流水线。演示在合成资产上证明机制,而不是一次部署。

这与 IBM watsonx Code Assistant 或大型系统集成商的工具链有何不同?

我们不声称胜过 IBM 或系统集成商的解析器,演示解析器覆盖现实的 COBOL 合成子集,而非每一种方言、ALTER 或 OCCURS DEPENDING ON。区别在于交付物:仓库感知的知识图谱,外加完备性证明和安全抽取顺序,而不是按文件转译。它是任何转译工作首先需要的理解层,也是更好的基座模型消除不了的那一层。

这是上线产品还是演示?

这是一份证明机制的可运行演示,不是已部署的流水线。银行资产为合成并专为本演示编写,因此真实依赖集由构造已知,这才使召回指标成为可复现的带标签测量,而不是一项声称。解析、图谱和全部四项分析都是确定性的普通 Python(FastAPI 加 networkx,Cytoscape.js 界面),无需 API 密钥、无需数据库即可运行。可选的问答 LLM 层存在但默认关闭,价值并不依赖它。

技术研究

本演示背后的研究——架构、核验设计,以及企业蓝图。

正在规划大型机现代化?

理解层才是难点。我们先建地图。

如果你的团队正在权衡如何现代化一套 COBOL 资产,而又不想因谁也看不见的依赖在 UAT 中措手不及,我们真心想听听你们现在怎么想。这个问题是全行业的,答案也将如此。

拓扑评估

  • ✓ 绘制一次变更跨越 copybook、DB2 和 JCL 所能到达的范围
  • ✓ 以 file:line 出处解析传递闭包
  • ✓ 对照真值集为依赖检索召回打分
  • ✓ 产出审计员所需的完备性证明

构建地图

  • ✓ 覆盖你真实资产的带类型知识图谱
  • ✓ 标记无法解析内容的完备性门禁
  • ✓ 可辩护的、已排序的绞杀藤抽取顺序
  • ✓ 可导出的 DORA ICT 资产与 SOC-2 变更控制报告
社交媒体

同步发布于