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 提供建議,程式碼做決定。
將資產剖析成具型別的圖譜,再執行確定性分析。關鍵路徑上沒有 LLM。
管線依序執行:夾具資產,然後剖析(COBOL、copybooks、JCL、DB2 DDL),然後建立具型別的知識圖譜,然後遞移閉包影響加上出處,然後確定性分析,然後稽核與證據匯出,然後互動儀表板。載入時應用程式透過 Server-Sent Events 即時執行這整條管線,因此每個階段在主控台以真實量測延遲旁白,面板逐步填入,而持久的階段軌道讓您開啟任一階段的 Input、Processing 與 Output 追蹤。單一控制即可重播整次執行。
以 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 個未解析節點。
這些是普通的圖譜演算法,不是模型呼叫,因此同一夾具每次執行都得到相同結果。
一次變更的遞移相依切片,每條邊帶有其檔案:行號來源,因此您不僅能看見什麼受影響,還能看見證據位於何處。
圖譜閉包對照夾具已知真實標註相依集計分,對比模擬的單檔視窗——那才是以文字為基礎的工具實際餵給模型的內容。
每支程式的耦合與波及範圍分數(耦合權重三、COMP-3 陷阱權重二、JCL 關鍵性權重二、未解析呼叫權重五),據此排出安全的絞殺榕遷移順序。
每一個 PERFORM、CALL、COPY 與 DB2 參照都必須解析,或標記為需審查,絕不可靜默丟棄。不可達的段落作為說明回報,不計為頭條指標。
一個切換讓差異變得具體。勾選樸素 AI 上下文視圖,圖譜就暗淡成單一來源檔案加上幾行上下文。九項電匯事實中有六項消失,紅色橫幅陳述後果,再切回去則以憑據還原 9/9。那個切換是在說明擷取層必須提供什麼上下文,而不是價值來源本身。
完成後,Export JSON 寫出 migration-evidence.json 檔案,Evidence report 則渲染可列印的程式碼庫拓撲與完整度報告:節點與邊摘要、各模組帶檔案:行號出處的閉包、召回率結果與方法、排序後的抽取序列、死碼清單,以及時間戳記。我們將其定位為 DORA ICT-asset 清冊與 SOC-2 變更控制憑據。可選的 Pydantic-AI 層可針對閉包回答問題,但預設關閉且以金鑰把關,確定性示範在沒有任何金鑰的情況下記錄結果。
對單一欄位的一次變更,對照已知真實標註集解析。下方每張圖都是執行中應用程式的螢幕截圖。
預設視圖落在電匯子系統,並已選取 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 之前執行,因此旗標在電匯運行前已設定。
勾選樸素 AI 上下文視圖,圖譜就暗淡成 WIRETXN.cbl 裡存在的內容。COMP-3 型別、REDEFINES 疊加、控制旗標、其兩個跨模組寫入者,以及 02:00 的 JCL 前置作業全部變灰,紅色橫幅陳述後果:只拿到三項看得見的事實時,模型產出普通的 long TRN_LIMIT,並把毀損的位元組寫入 ACCOUNTS.TRN_LIMIT,這就是 UAT 失敗。這正是文字視窗工具在結構上無法彌合的脈絡盲點缺口,一鍵即可看見。
抽取視圖依耦合與波及範圍分數為全部 14 支程式排名。AUDITLOG 是安全的首個抽取,排名 1、風險分數 0、耦合為零。WIRETXN 位於排名 11(風險 4,一個 COMP-3 陷阱加上 JCL 關鍵性)。DISPATCH 因未解析的動態 CALL 排名 12(風險 5),上帝程式 ACCTMGR 最後抽取,排名 14(耦合 5,風險 15)。那是您能辯護的絞殺榕順序:最低風險最先,最高耦合最後。
稽核分頁回報 97.1% 的參照已解析,也就是 34 項中的 33 項,恰好 1 項標記待審查,而非靜默丟棄。那一項是 DISPATCH 的動態 CALL WS-PROGNAME,其目標在執行期計算(DISPATCH.cbl:15),因此無法靜態解析。該分頁也依可達性列出死碼:AUDITLOG 的 LEGACY-FORMAT 段落與 WIRETXN 的 OLD-LIMIT-CHECK 段落不可達。拒絕偽造解析才是誠實行為,也是監管者想看到的行為。
以上全部匯出為可列印的程式碼庫拓撲與完整度報告:47 節點、70 邊的摘要、97.1% 覆蓋、九項 TRN-LIMIT 相依事實及其單檔可見性與檔案:行號出處、排序後的抽取序列,以及產生時間戳記。因為資產是合成且專為撰寫,真實相依集在建構時即已知,這才讓召回率數字成為可重現的標註量測,而不是一句宣稱。我們把 9/9、3/9 與 97.1% 歸於這份隨附夾具,從不當作任意 COBOL 資產上的開放世界保證。
示範用來對比的同一個切換,並排呈現在電匯夾具上。
| 維度 | 單檔上下文視窗 | CodeGraph 知識圖譜 |
|---|---|---|
| 找回的 TRN-LIMIT 相依 | 9 項中的 3 項 | 9 項中的 9 項,對照已知真實標註集 |
| 跨 copybooks 的 COMP-3 型別 | 看不見 | 已解析,帶檔案:行號出處 |
| REDEFINES 疊加與控制旗標 | 看不見 | 已解析,含跨模組寫入者 |
| 僅存在於 JCL 的順序邊(NIGHTLY 在 WIREJOB 之前) | 看不見 | 建模為 PRECEDES 邊 |
| 完整度證明 | 無 | 97.1% 已解析,未解析者標記待審查 |
| 安全抽取順序 | 無 | 依耦合與波及範圍排名 |
| 稽核成品 | 無 | 可匯出的拓撲與完整度報告 |
不是。CodeGraph 是理解層,不是轉譯器,它刻意不做貼上 COBOL 再產出 Java。它為您的資產建立具型別的相依圖譜,並解析一次變更所觸及的精確遞移切片,帶有檔案:行號出處與完整度證明。轉譯是下游的使用情境,而每一個轉譯工具仍需要這張地圖,才能知道一次變更實際觸及什麼。
不能,而這正是持久的重點。真實資產有 1 to 10 million 行或更多,塞不進任何現有或未來的上下文視窗。困難的部分是擷取精確的遞移切片,並證明您找全了,那是拓撲、擷取與證據問題,不是推理品質問題。完美的模型仍然無法向監管者證明擷取了哪些相依,仍然需要安全的抽取順序,仍然欠一份 ICT-asset 清冊。
完整度閘門要求每一個 PERFORM、CALL、COPY 與 DB2 參照要嘛解析,要嘛標記待審查,絕不可靜默丟棄。在隨附夾具上,那是 34 項中的 33 項參照已解析,也就是 97.1% 覆蓋,那一項無法解析的參照被標記。您可以匯出可列印的程式碼庫拓撲與完整度報告,含節點與邊摘要、各模組帶檔案:行號出處的閉包、召回率結果與方法、排序後的抽取序列,以及死碼清單,定位為 DORA ICT-asset 清冊與 SOC-2 變更控制憑據。
它會被標記待審查,而不是靜默丟棄,那種誠實行為才是重點。在夾具上,那一項無法解析的參照是 DISPATCH 的動態 CALL WS-PROGNAME,其目標在執行期計算(DISPATCH.cbl:15),因此無法靜態解析。CodeGraph 將它記錄為需審查,並正因這個理由把 DISPATCH 排在安全抽取順序接近末端。
在本示範中不會。圖譜採記憶體內加上 SQLite,DB2、JCL 與排程器輸入是檔案夾具,而樸素單檔視圖是模擬的上下文視窗。正式部署會指名 Neo4j 或 Memgraph 這類圖譜平台並讀取您的真實資產,但此處沒有任何內容暗示即時 z/OS 管線。本示範在合成資產上證明機制,不是一次部署。
我們並不宣稱勝過 IBM 或系統整合商的剖析器,且示範剖析器涵蓋的是 COBOL 的寫實合成子集,不是每一種方言、ALTER 或 OCCURS DEPENDING ON。區別在於交付物:一份能感知整個儲存庫的知識圖譜,加上完整度證明與安全抽取順序,而不是逐檔轉譯。它是任何轉譯工作都必須先有的理解層,也是更好的基礎模型消除不了的那一層。
這是證明機制的可運行示範,不是已部署的管線。銀行資產為專為本示範撰寫的合成資料,因此真實相依集在建構時即已知,這才讓召回率指標成為可重現的標註量測,而不是一句宣稱。剖析、圖譜與全部四項分析都是確定性的純 Python(FastAPI 加上 networkx、Cytoscape.js 介面),無需 API 金鑰、也無需資料庫即可執行。可選的 LLM 問答層存在但預設關閉,價值並不依賴它。
理解層才是困難的部分。我們先建立地圖。
若您的團隊正在衡量如何現代化 COBOL 資產,以免因沒人看得見的相依而在 UAT 碰上意外,我們真心想聽聽您怎麼想。這個問題是全產業的,答案也會是。