COBOL 現代化智慧

我們在動到任何一行之前,先建立您程式碼庫的地圖。

多數現代化專案之所以失敗,是因為工具把程式碼當文字讀,而不是當拓撲。CodeGraph 將您的大型主機資產剖析成具型別的知識圖譜,並解析一次變更的完整遞移相依閉包——橫跨 copybooks、REDEFINES、COMP-3、DB2 與 JCL——每條邊都帶有檔案:行號出處,並證明它能解析多少。地圖才是產品。轉譯是下游的使用情境。

9/9 vs 3/9

找回的相依:圖譜對比單檔視窗

在 TRN-LIMIT 夾具上,對照已知真實標註集

97.1%

已解析的參照(34 項中的 33 項),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 是定義在三層 copybooks 之外的 COMP-3 壓縮十進位,其解讀由另一支程式設定的旗標決定,而該旗標由凌晨 2 點、在電匯作業之前執行的 JCL 批次作業寫入。只拿到看得見的事實時,模型產出一個普通的 long,Java 能編譯、單元測試通過,然後在第一筆正式電匯時毀損資料庫。那個參照完整性失敗在 UAT 才浮現。失敗源於脈絡盲點。

這不會隨模型進步而過時。真實資產有 1 to 10 million 行或更多,塞不進任何現有或未來的上下文視窗。困難的部分是擷取一次變更所觸及的精確遞移切片,並證明您找全了。那是拓撲、擷取與證據問題,不是推理品質問題。Agent 提供建議,程式碼做決定。

CodeGraph 如何運作

將資產剖析成具型別的圖譜,再執行確定性分析。關鍵路徑上沒有 LLM。

管線依序執行:夾具資產,然後剖析(COBOL、copybooks、JCL、DB2 DDL),然後建立具型別的知識圖譜,然後遞移閉包影響加上出處,然後確定性分析,然後稽核與證據匯出,然後互動儀表板。載入時應用程式透過 Server-Sent Events 即時執行這整條管線,因此每個階段在主控台以真實量測延遲旁白,面板逐步填入,而持久的階段軌道讓您開啟任一階段的 Input、Processing 與 Output 追蹤。單一控制即可重播整次執行。

CodeGraph 介面正對 WIRETXN 程式執行即時分析管線,主控台顯示各階段延遲:掃描、剖析、建立圖譜、影響閉包、還原事實,以及規劃與稽核。
即時管線:掃描、剖析、建立圖譜、影響閉包、還原事實,以及規劃與稽核,每個階段都帶有真實量測延遲。

具型別的知識圖譜

以 networkx 建構並保存在記憶體內加上 SQLite,圖譜有七種節點類型(program、copybook、variable、table、jcl、dataset,以及 unresolved placeholder)以及型別化的邊,例如 DEFINES、IMPORTS、REDEFINES、CONTROLS_TYPE_OF、WRITES_VAR、REFERENCES、CALLS、READS 與 WRITES、EXECUTES、USES_DATASET 與 PRECEDES。在隨附夾具上,圖譜有 47 個節點與 70 條邊:14 支程式、5 個 copybooks、17 個變數、3 張 DB2 資料表、3 個 JCL 作業、4 個 datasets,以及 1 個未解析節點。

四項確定性分析

這些是普通的圖譜演算法,不是模型呼叫,因此同一夾具每次執行都得到相同結果。

1. 帶出處的影響閉包

一次變更的遞移相依切片,每條邊帶有其檔案:行號來源,因此您不僅能看見什麼受影響,還能看見證據位於何處。

2. 樸素對比圖譜召回率

圖譜閉包對照夾具已知真實標註相依集計分,對比模擬的單檔視窗——那才是以文字為基礎的工具實際餵給模型的內容。

3. 抽取排序

每支程式的耦合與波及範圍分數(耦合權重三、COMP-3 陷阱權重二、JCL 關鍵性權重二、未解析呼叫權重五),據此排出安全的絞殺榕遷移順序。

4. 死碼可達性與完整度閘門

每一個 PERFORM、CALL、COPY 與 DB2 參照都必須解析,或標記為需審查,絕不可靜默丟棄。不可達的段落作為說明回報,不計為頭條指標。

一個切換讓差異變得具體。勾選樸素 AI 上下文視圖,圖譜就暗淡成單一來源檔案加上幾行上下文。九項電匯事實中有六項消失,紅色橫幅陳述後果,再切回去則以憑據還原 9/9。那個切換是在說明擷取層必須提供什麼上下文,而不是價值來源本身。

完成後,Export JSON 寫出 migration-evidence.json 檔案,Evidence report 則渲染可列印的程式碼庫拓撲與完整度報告:節點與邊摘要、各模組帶檔案:行號出處的閉包、召回率結果與方法、排序後的抽取序列、死碼清單,以及時間戳記。我們將其定位為 DORA ICT-asset 清冊與 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)寫入該旗標;以及 JCL 作業 NIGHTLY 於 02:00 在 WIREJOB 之前執行,因此旗標在電匯運行前已設定。

TRN-LIMIT 影響面板:圖譜擷取 9/9 對比樸素單檔 3/9,事實 F1 至 F3 標為檔內,F4 至 F9 標為隱藏且關鍵或高,每一項都帶有檔案:行號出處。
圖譜擷取 9/9 對比樸素單檔 3/9。三項看得見的事實在檔內;決定型別的六項對單檔視圖隱藏,每一項都帶有檔案:行號出處。

關鍵一擊:切到單檔視窗,看六項事實消失

勾選樸素 AI 上下文視圖,圖譜就暗淡成 WIRETXN.cbl 裡存在的內容。COMP-3 型別、REDEFINES 疊加、控制旗標、其兩個跨模組寫入者,以及 02:00 的 JCL 前置作業全部變灰,紅色橫幅陳述後果:只拿到三項看得見的事實時,模型產出普通的 long TRN_LIMIT,並把毀損的位元組寫入 ACCOUNTS.TRN_LIMIT,這就是 UAT 失敗。這正是文字視窗工具在結構上無法彌合的脈絡盲點缺口,一鍵即可看見。

樸素單檔上下文視圖:紅色橫幅說明只有 9 項中的 3 項事實存在於 WIRETXN.cbl 內,事實 F4 至 F9 變灰,包括 COMP-3 型別、REDEFINES 疊加、控制旗標,以及 02:00 的 JCL 前置作業。
樸素單檔視圖:六項事實暗淡,紅色橫幅陳述因此導致的正式環境失敗。切回去,9/9 連同憑據一併回來。

安全的抽取順序,依波及範圍排名

抽取視圖依耦合與波及範圍分數為全部 14 支程式排名。AUDITLOG 是安全的首個抽取,排名 1、風險分數 0、耦合為零。WIRETXN 位於排名 11(風險 4,一個 COMP-3 陷阱加上 JCL 關鍵性)。DISPATCH 因未解析的動態 CALL 排名 12(風險 5),上帝程式 ACCTMGR 最後抽取,排名 14(耦合 5,風險 15)。那是您能辯護的絞殺榕順序:最低風險最先,最高耦合最後。

抽取序列表依耦合、COMP-3 陷阱、JCL 關鍵性與風險分數為 14 支程式排名,AUDITLOG 最先、風險 0,上帝程式 ACCTMGR 最後、風險 15,旁邊是舊有到已現代化的 diff 視圖。
絞殺榕順序:AUDITLOG 最先、風險 0,ACCTMGR 最後、風險 15,各排名理由顯示在耦合、陷阱與 JCL 欄。

標記無法解析項目的完整度閘門

稽核分頁回報 97.1% 的參照已解析,也就是 34 項中的 33 項,恰好 1 項標記待審查,而非靜默丟棄。那一項是 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% 覆蓋、九項 TRN-LIMIT 相依事實及其單檔可見性與檔案:行號出處、排序後的抽取序列,以及產生時間戳記。因為資產是合成且專為撰寫,真實相依集在建構時即已知,這才讓召回率數字成為可重現的標註量測,而不是一句宣稱。我們把 9/9、3/9 與 97.1% 歸於這份隨附夾具,從不當作任意 COBOL 資產上的開放世界保證。

可列印的程式碼庫拓撲與完整度報告,顯示 47 個節點、70 條邊、97.1% 參照已解析、TRN-LIMIT 相依事實 F1 至 F9 及其單檔可見性與出處,以及絞殺榕抽取序列。
可匯出的程式碼庫拓撲與完整度報告:節點與邊摘要、九項帶出處的相依事實,以及排序後的抽取序列,定位為 DORA ICT-asset 清冊。

單檔上下文視窗對比圖譜

示範用來對比的同一個切換,並排呈現在電匯夾具上。

維度 單檔上下文視窗 CodeGraph 知識圖譜
找回的 TRN-LIMIT 相依 9 項中的 3 項 9 項中的 9 項,對照已知真實標註集
跨 copybooks 的 COMP-3 型別 看不見 已解析,帶檔案:行號出處
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。它為您的資產建立具型別的相依圖譜,並解析一次變更所觸及的精確遞移切片,帶有檔案:行號出處與完整度證明。轉譯是下游的使用情境,而每一個轉譯工具仍需要這張地圖,才能知道一次變更實際觸及什麼。

更大的上下文視窗或更好的模型,不就能解決這個問題嗎?

不能,而這正是持久的重點。真實資產有 1 to 10 million 行或更多,塞不進任何現有或未來的上下文視窗。困難的部分是擷取精確的遞移切片,並證明您找全了,那是拓撲、擷取與證據問題,不是推理品質問題。完美的模型仍然無法向監管者證明擷取了哪些相依,仍然需要安全的抽取順序,仍然欠一份 ICT-asset 清冊。

您如何向稽核人員證明找全了每一項相依?

完整度閘門要求每一個 PERFORM、CALL、COPY 與 DB2 參照要嘛解析,要嘛標記待審查,絕不可靜默丟棄。在隨附夾具上,那是 34 項中的 33 項參照已解析,也就是 97.1% 覆蓋,那一項無法解析的參照被標記。您可以匯出可列印的程式碼庫拓撲與完整度報告,含節點與邊摘要、各模組帶檔案:行號出處的閉包、召回率結果與方法、排序後的抽取序列,以及死碼清單,定位為 DORA ICT-asset 清冊與 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 碰上意外,我們真心想聽聽您怎麼想。這個問題是全產業的,答案也會是。

拓撲評估

  • ✓ 對映一次變更能橫跨 copybooks、DB2 與 JCL 抵達何處
  • ✓ 以檔案:行號出處解析遞移閉包
  • ✓ 對照真實標註集為相依擷取召回率計分
  • ✓ 產出稽核人員所需的完整度證明

建立地圖

  • ✓ 覆蓋您真實資產的具型別知識圖譜
  • ✓ 標記無法解析項目的完整度閘門
  • ✓ 可辯護、已排名的絞殺榕抽取順序
  • ✓ 可匯出的 DORA ICT-asset 與 SOC-2 變更控制報告
社群媒體

同步發佈於