場 TRANS-AMT-CD COBOL 程式中的這項功能自 1981 年以來一直在生產中使用。 FD 條目將其定義為： PIC S9(9)V99 COMP-3這是一個壓縮的十進制帶符號數值字段，包含 11 位數字，隱含兩位小數。這是技術元資料。而業務元數據，即 TRANS-AMT-CD 的實際意義、計價貨幣、兩位隱含小數代表的是美分還是基點、負值代表的是貸項還是藉項，以及零值應如何解釋，在代碼庫中並不存在。它存在於一份 1981 年印刷的功能規格文件中，該文件被存檔於文件櫃中，此後便杳無音訊。最初了解 TRANS-AMT-CD 意義的兩位開發人員均已於 2014 年退休。
這是所有擁有數十年資料系統的組織都會面臨的元資料困境，也是現代資料治理框架無法解決的問題。 Collibra、Alation、Atlan 以及其他所有企業資料目錄平台都非常擅長管理已描述資料的元數據，例如具有文件化模式的雲端資料庫、具有明確列語義的資料倉儲以及符合 OpenAPI 規範的 API 端點。但它們無法重建從未正式捕獲的元數據，這些元數據僅存在於元數據管理成為一門學科之前編寫的程序的行為中，並且在過去四十年中被數十位開發人員修改過，卻沒有人更新過每個字段含義的中央記錄。
針對跨越數十年的資料系統的元資料管理，與針對現代系統的元資料管理截然不同。它需要一種根本不同的方法，這種方法從來源資料中提取元資料開始，而不是從連接的系統中攝取元資料。
遺留元資料的三層結構
要了解數十年系統中的元資料問題，需要認識到這些環境中的元資料存在於三個不同的層次中，每個層次的可提取性、完整性和治理影響都不同。
技術元資料是最容易擷取的層。它描述了資料的物理結構：欄位名稱、資料類型、長度、在記錄中的位置、數值精確度規格以及記錄佈局中欄位之間的關係。在 COBOL 環境中，技術元資料存在於原始碼工件中：FD 條目定義記錄佈局，COPY 成員定義可重複使用的資料結構，SELECT 子句定義檔案組織和存取方法，JCL DD 語句定義與每次程式執行關聯的資料集。原則上，這一層是機器可讀的，能夠理解 COBOL 語法的解析器可以從原始碼中提取它，但它分佈在數千個原始檔中，而不是集中在模式註冊表中。
操作元資料描述了資料在系統中的流動方式：哪些程式產生哪些資料集，哪些程式使用這些資料集，它們的順序是什麼，以及經過哪些轉換。在大型主機環境中，操作元資料分佈在 JCL 作業流程（定義執行順序和資料集關聯）、程式呼叫圖（定義程式間資料流）以及調度器配置（定義時間和相依性）。雖然這一層也可以從來源工件中透過機器提取，但提取過程不僅需要理解單一程序，還需要理解它們之間的關係。
業務或語意元數據 這是最難提取但最有價值的一層。它回答了技術元資料無法回答的問題：什麼 TRANS-AMT-CD 從商業角度來看，這究竟意味著什麼？哪些值是有效的？ ACCT-TYPE-CD 每個值分別代表什麼？什麼業務規則決定何時使用哪個值？ CUST-STATUS-FLG 從過渡 A 至 I這一層如果存在的話，存在於規範文件、開發人員的記憶、可能已經退休的員工所掌握的機構知識，以及透過 IF 語句和 EVALUATE 區塊而不是透過資料庫約束來強制執行業務規則的程式的程式邏輯中。
對於跨越數十年的系統而言，元資料面臨的挑戰在於，這三個層面的元資料在數十年的系統演進過程中，要麼管理方式各不相同，要麼根本沒有管理。技術元資料雖然記錄在原始程式碼中，但從未正式形成資料字典。操作元資料隱含在 JCL 作業流程中，但從未以血緣記錄進行文件化。業務元資料在初始開發階段的規格中有所記載，但隨著系統的演進，從未進行更新。
元資料漂移問題
如果一個運行數十年的系統缺乏系統的元資料管理，那麼每年正式文件中存在的元資料與反映系統當前實際行為的元資料之間的差距都會擴大。這種偏差是透過以下四種機制產生的：
領域含義演變。 1978 年被定義為具有一種商業意義的領域，在隨後的幾十年中可能累積了其他意義。 ACCT-TYPE-CD 最初可能用於區分行票帳戶和儲蓄帳戶。四十多年來，可能添加了其他代碼來表示貨幣市場帳戶、定期存款、個人退休帳戶（IRA）和託管帳戶，但每次添加的代碼都只記錄在處理新代碼值的程序代碼中，而沒有記錄在任何中央字段定義中。欄位的名稱和類型保持不變；但其語義含義已變得複雜得多。
悄無聲息的再利用。 欄位有時會在不重新命名的情況下重新用於其他用途。例如，某個欄位原本用於某種目的，但後來擴展起來變得不方便，於是開發人員利用相鄰標誌欄位中之前未使用的值來編碼不同的資訊。 TRANS-FLAG-1 現在，該欄位可能在不同的程式上下文中編碼三個不同的概念，只有透過檢查哪些程式讀取該欄位以及在什麼條件下讀取該欄位才能區分它們。技術元資料（欄位名稱、類型、長度）並未顯示該欄位存在語意重載。
REDEFINES 累積。如同在 VSAM 分析上下文中所述，REDEFINES 子句使用不同的欄位解釋覆蓋相同的物理儲存。每個 REDEFINES 變體可能由不同的開發人員在系統歷史的不同階段出於不同的業務目的添加。 REDEFINES 層次結構的完整語義意義（即何時應用哪個變體以及每個變體的字段含義）只能透過分析存取每個變體的所有程序及其存取條件來重建。
副本差異。當標準的 COBOL 副本被修改以滿足新的需求時，包含該副本但未更新以處理新欄位的程式可能會執行異常，或直接忽略新欄位。經過數十年的發展，名義上相同的副本可能在不同的庫中存在多個版本，不同的程式使用不同的版本。副本中定義的欄位的元資料可能會因程式包含的副本版本不同而有所差異。
現代元資料工具無法為遺留資料做什麼
企業資料目錄市場已日趨成熟。 Collibra、Alation、Atlan、Microsoft Purview 和 Informatica Axon 都是功能強大的平台，可用於管理現代資料環境中的元資料。它們的優點在於：自動發現連接資料庫中的模式、追蹤 ETL 管道中列級的資料沿襲、維護包含精心整理的術語定義的業務詞彙表，以及在元資料記錄旁邊顯示資料品質指標。
這些工具無法為運行數十年的 COBOL 和大型主機系統做什麼：
它們無法連接到它們看不到的內容。現代目錄透過連接器、與資料庫的 JDBC 連接、與雲端服務的 API 整合以及與受支援平台的掃描器整合來發現元資料。 VSAM 檔案、COBOL 程式和 JCL 作業流程沒有標準的目錄連接器。目錄無法發現它沒有機制存取的內容。這些系統管理的數據對目錄來說實際上是不可見的，這意味著基於這些數據的下游雲分析的血緣記錄不完整或缺失。
它們無法提取僅存在於程式碼中的元資料。連接到 DB2 資料庫的資料目錄可以讀取資料庫模式、表定義、列名、資料類型和索引。但它無法讀取填充 DB2 表的 COBOL 程序，因此無法了解哪些業務規則控制資料填充、來源記錄中存在哪些 REDEFINES 變體，或哪些 88 級條件名稱定義了每個欄位的語義有效性。程式碼級元資料（即遺留資料業務意義實際存在的層）需要進行程式碼分析，而不是目錄掃描。
他們無法重構從未被記錄的含義。即使技術元資料擷取完美無缺，也無法自動重構從未正式記錄的欄位的業務意義。這一層需要結合程式碼分析（揭示程序應用於資料的業務規則，這些規則是業務意義的代理）和人工審核（在機構知識仍然存在的情況下，驗證重構的含義是否與這些知識相符）。
元資料重建方法
對於那些從未收集過正式元資料或元資料與實際情況嚴重偏離的多年代系統，元資料管理需要在治理階段之前先進行重建。重建方法提取可恢復的元資料層，並識別出需要人工知識填補的空白區域。
第一階段：從來源工件擷取技術元資料。
解析每個 COBOL FD 條目、COPY 成員、SELECT 子句和 JCL DD 語句，以產生欄位層級技術元資料清單：
科博爾
* Source FD entry -- technical metadata extraction target
FD TRANSACTION-FILE
LABEL RECORDS ARE STANDARD
RECORD CONTAINS 200 CHARACTERS.
01 TRANSACTION-RECORD.
05 TRANS-DATE PIC 9(8). *> YYYYMMDD format
05 TRANS-TYPE-CD PIC XX. *> See 88-level values
88 TRANS-PAYMENT VALUE 'PM'.
88 TRANS-REFUND VALUE 'RF'.
88 TRANS-ADJUSTMENT VALUE 'AJ'.
88 TRANS-REVERSAL VALUE 'RV'.
05 TRANS-AMT-CD PIC S9(9)V99 COMP-3.
05 TRANS-CURRENCY-CD PIC X(3). *> ISO 4217
05 TRANS-DETAIL REDEFINES TRANS-TYPE-CD.
10 TRANS-MERCH-ID PIC X(12).
10 TRANS-AUTH-CD PIC X(6).
10 FILLER PIC X(84).從這一 FD 條目中，技術元資料擷取可產生：欄位名稱、資料類型、長度、位置、壓縮十進位精度 TRANS-AMT-CD （9 位數字，2 位小數，帶符號），四個語意值 TRANS-TYPE-CD 根據 88 級條件名稱和 REDEFINES 結構定義，該結構創建了記錄的第 10-105 個位元組的兩種重疊解釋。
88級條件名稱作為元資料尤其有價值： TRANS-PAYMENT, TRANS-REFUND, TRANS-ADJUSTMENT, TRANS-REVERSAL COBOL 程式碼本身提供了四個商業詞彙，這些詞彙比底層程式碼更有意義。 PM, RF, AJ, RV 資料目錄掃描資料庫時會看到的值。
第二階段：從程式相依性中提取操作元資料。
透過追蹤程式依賴關係圖中的資料流，建立操作譜系圖：
- 哪些程式會寫入
TRANSACTION-FILE（製片） - 哪些程式會讀取
TRANSACTION-FILE（消費者） - 哪些 JCL 作業步驟會呼叫每個生產者和消費者，呼叫順序是什麼？
- 哪些下游資料集和資料庫會接收轉換後的資料？
TRANSACTION-FILE
此血統圖是資料目錄工具進行血統視覺化所需的操作元數據，但如果沒有存取原始程式碼和 JCL，則無法建立此元資料。
第三階段：業務規則提取作為語意元資料代理。
以 COBOL PROCEDURE DIVISION 邏輯編碼的業務規則是業務意義的代理。一個驗證程序 TRANS-AMT-CD 為了確保處理前資料落在特定範圍內，需要提供有關該欄位有效範圍的證據。一個轉換程序 TRANS-AMT-CD 在寫入下游系統之前轉換為不同的單位，會揭示隱含的小數或單位約定。
透過程式碼分析提取這些業務規則，可以產生一組推斷出的語意元資料：應用於每個欄位的驗證範圍、來源資料和目標資料之間發生的轉換，以及不同程式碼路徑的執行條件。這種推斷出的語義元數據並不精確，它顯示的是程式如何處理數據，而非數據原本的含義，但它可以從程式碼中恢復，而原始規範文檔則無法做到這一點。
第四階段：人工驗證和語意增強。
提取的技術和操作元數據以及推斷的語義元數據構成了與領域專家和即將退休的開發人員進行人工驗證的基礎。目標是將推斷的語義轉換為已確認的語義，從而驗證… TRANS-AMT-CD 意味著程式碼所暗示的含義，識別程式碼行為不再反映預期業務含義的情況，並捕捉程式碼分析無法恢復的有關領域歷史的機構知識。
這一階段的時間取決於領域專業知識的可用性：每年都有越來越多的此類知識隨著掌握這些知識的人退休而消失。
現代系統邊界處的傳統元資料差距
數十年歷史的系統造成的元資料缺失並不會侷限於原有環境，而是會向下游蔓延：所有使用原有系統資料的分析系統、資料倉儲和機器學習流程都會繼承這一元資料缺口。
一個雲端資料倉儲每晚都會接收來自 COBOL 批次程式的平面檔案擷取數據，其列定義中包含資料工程團隊在建置 ETL 管道時選擇的資料列名稱。如果原始欄位是 TRANS-AMT-CD ETL開發人員將目標列命名為 transaction_amount資料倉儲似乎擁有完整的元資料：列名、資料類型、業務描述等都已添加到目錄中。但目錄沒有記錄的是： transaction_amount 來源於 TRANS-AMT-CD in TRANSACTION-FILE這是由一個名為 的 COBOL 程式產生的。 TRNSRC01它在 JCL 作業中運行 TRANSDAY 每天凌晨 2 點，系統都會應用一種特定的貨幣轉換，這種轉換是根據 1987 年根據匯率慣例硬編碼的，而這種匯率慣例可能仍然有效，也可能無效。
下游元資料記錄看起來完整。但血統關係在舊版邊界處斷開。任何依賴於理解來源和含義的分析或人工智慧工作負載都將受到影響。 transaction_amount 其中存在一個空白，即該價值觀的實際起源故事並沒有被記錄下來。
Gartner 的一項研究發現，到 2026 年，60% 缺乏 AI 就緒資料支援的 AI 專案將被放棄，這部分內容是對元資料的描述。 AI 模型需要消耗這些數據。 transaction_amount 在不知情的情況下，模型正在使用來源不明的資料進行訓練。這些數據源自於一個包含隱含小數位的壓縮十進制 COBOL 字段，且以某種可能使用 1987 年匯率慣例轉換的貨幣計價。由於模型或其資料管道可存取的任何目錄中都不存在能夠傳達此資訊的元數據，因此模型無法識別並針對此上下文進行調整。
為遺留系統建立元資料管理程序
針對跨越數十年的資料系統的元資料管理程序包含四個與標準企業資料目錄實作方式不同的元件：
元件 1：原始碼元資料提取。任何目錄工具要管理遺留元數據，必須先從元資料所在的來源工件中提取元資料。此提取過程必須涵蓋：FD 條目和副本（資料結構的技術元資料）、SELECT 子句（文件組織和存取方法）、JCL DD 語句（資料集關聯和文件特徵）以及 88 層條件名稱（嵌入原始碼中的語意值詞彙表）。輸出結果是一個欄位級元資料清單，可以將其載入到目錄中，作為業務增強的起點。
組件 2：資料沿襲重建。遺留系統的資料沿襲必須透過程式依賴性分析重建，而不是透過 ETL 工具的沿襲追蹤。沿襲圖追蹤資料從其原始 COBOL 程式經由中間轉換程式直到最終使用者的整個流程，包括將資料交付給現代分析系統的 ETL 流程。這種重建彌合了遺留系統邊界處的沿襲差距，透過記錄的程式依賴關係鏈，將雲端資料倉儲的列元資料與 COBOL FD 條目元資料連接起來。
組件 3：利用領域專業知識進行語意豐富。 擷取的技術元資料提供了結構；確認業務意義則需要領域專業知識。豐富過程使用技術元資料作為結構化提示，引導專家訪談：“此欄位定義為…” PIC S9(9)V99 COMP-3該值在 14 個程式中被驗證為非負值，並且在寫入下游資料庫之前轉換為不同的尺度，您能否確認它代表什麼以及轉換的含義？ 「這種結構化方法利用程式碼分析來最大限度地提高每次專家互動的資訊價值，從而實現比非結構化文件審查更快、更全面的資訊豐富。
組件 4：與現代目錄平台的治理整合。提取、重建和豐富傳統元資料後，必須將其與現代元資料治理基礎架構整合。此整合將傳統元資料清單連接到企業資料目錄，提供：從 COBOL 來源到雲端目標的列級沿襲、連結到傳統欄位定義的業務術語表，以及填充與現代系統元資料相同治理框架的傳統資料集的資料品質元資料。
SMART TS XL 提取遺留元數據
SMART TS XL 透過對整個 COBOL、JCL 和副本組合應用靜態分析，解決了遺留元資料管理程式的前兩個組成部分：原始碼元資料提取和血統重建。
靜態程式碼分析功能解析 COBOL 程式集中所有 FD 條目、COPY 成員、SELECT 子句和 88 級定義，產生欄位層級技術元資料清單：包括環境中每個程式和副本的每個欄位名稱、資料類型、長度、COMP 規格、REDEFINES 成員關係和 88 級條件名稱。對於包含數千個 COBOL 程式的組件，此擷取功能只需數小時即可產生技術元資料清單，而手動編寫文件則需要數年時間才能完成，甚至根本無法完成。
應用程式依賴關係映射建構了操作血緣關係圖：它記錄了所有程式與資料集之間的關係（哪些程式產生哪些資料集，哪些程式使用這些資料集）、所有程式與程式之間的依賴關係（哪些程式呼叫哪些其他程序，以及它們之間有哪些資料流），以及所有 JCL 與程式之間的關係順序呼叫哪些作業程序）。這張血緣關係圖是操作元資料層，它彌合了傳統來源系統與現代資料目錄血緣記錄之間的差距。
JCL擴展功能追蹤每個 JCL 作業的完整執行鏈：解析 PROC 引用、擴展符號參數，並為每個資料集的產生和使用建立完整的操作元資料、排程上下文、依賴作業以及決定每個資料集的及時性和新鮮度特徵的執行順序。
企業級搜尋功能使提取的元資料清單可在整個元資料管理程序中查詢：查找所有定義為 COMP-3 的字段（精度要求高的字段，需要仔細的目標映射）、所有讀取特定字段的程序（識別特定資料的所有使用者，以便進行沿襲和語義增強）、以及所有與特定業務術語（將業務）匹配的 88 級詞彙條件（將業務定義）。此搜尋功能支援語義增強過程，使領域專家能夠在確認特定欄位或值的業務含義之前，尋找其所有使用情況。
對於進行以下活動的組織 遺產現代化 程式， SMART TS XL的元資料擷取提供了遷移前的基礎：遷移工具需要欄位層級技術元資料來將來源欄位對應到目標模式，遷移程式需要操作血統來正確排序資料集遷移，以及能夠將 COBOL 程式碼值準確地對應到關係約束定義的 88 級語意詞彙表。
知識退化前元資料復原的迫切性
元資料重建問題有一個天然的截止日期，而大多數資料治理挑戰並不存在這個截止日期：掌握著程式碼分析無法恢復的機構知識的開發人員即將退休。到2030年，將有近三分之一的COBOL程式設計師退休。大型主機工程師的平均年齡為58.7歲。每過一年，如果無法有系統地提取元資料並進行語義增強，那麼人工驗證已恢復元資料的時間視窗就會縮小一分。
技術元數據，例如欄位定義、類型規格、程式依賴關係和資料沿襲，只要原始碼存在，就可以無限期地從原始程式碼中恢復。而語義元數據，例如每個字段在業務上的含義、字段設計背後的歷史決策以及技術規範中未記錄的隱含約定，只能從了解這些信息的人員那裡恢復，並且只有在他們仍然在職時才能恢復。
針對運行數十年的系統，如果元資料管理程式從技術提取入手，並在領域專家仍在世時進行語意豐富，就能產生完整且可恢復的元資料基礎。而同樣的程序如果推遲到相關知識退役之後再進行，則只能產生準確但不完整的技術元資料基礎，雖然能夠正確描述資料結構，卻無法揭示其意義。
元資料就是地圖。數十年的系統將其掩埋。
現代系統的資料治理始於及時更新、易於存取且至少部分記錄在案的元資料。而對於運行數十年的系統而言，其數據治理則始於分散在數千個原始碼檔案中的元數據，這些元數據部分記錄在互聯網出現之前的規範中，部分則僅存於即將退休的開發人員的記憶中。
從底層資料到可控數據，其路徑依序經歷擷取、重構和豐富三個步驟。從原始碼中提取的技術元資料構成初始清單。從程序依賴關係重構的操作譜系構成溯源圖。經領域專家驗證的語意豐富賦予技術元資料業務意義，使其可用於分析、人工智慧和治理。
現代資料目錄平台是這些元資料的目的地，而不是起點。在 Collibra 能夠管理這些元資料、Alation 能夠對其進行編目、資料科學家能夠信任這些元資料之前，必須先在 FD 條目、副本簿、88 級條件名稱以及編碼在四十年 PROCEDURE DIVISION 邏輯中的業務規則中找到這些包含數十年歷史的系統所蘊含的元資料。
地圖就在那裡，只是需要有人解讀。
