IMS並非傳統意義上的過時系統。它是大型銀行應收帳款、保險公司保單管理以及醫療支付機構理賠處理的資料庫引擎。 IBM仍在繼續開發它。問題不在於IMS停止運行，而是所有熟悉其層級結構樹的開發人員都已退休，對基於IMS的系統進行任何更改都需要理解一個沒有SQL的資料模型，而任何將IMS視為關聯式資料庫的遷移計劃最終都會付出慘痛的代價。
最糟糕的情況莫過於在遷移過程中發現，某個 COBOL 程式存取 IMS 並非透過簡單的鍵查找，而是透過層級遍歷，而這種層級遍歷必須在目標系統中以等效的導航邏輯進行複製。又或發現兩個實體 IMS 資料庫之間的邏輯關係造成了依賴關係，而這兩個資料庫的資料庫定義文件 (DBD) 均未對此進行完整記錄，導致遷移過程中兩個資料庫各自獨立地進行了轉換，卻悄無聲息地破壞了所有使用該邏輯關係的程式。再或發現，一個關鍵的報表程式存取其資料的唯一途徑竟然是輔助索引資料庫（大多數遷移計畫都不會考慮這種結構）。
這些意外情況在經過嚴格的遷移前依賴性分析後都無法成立。但它們在假設條件下卻能成立。
IMS依賴性分析有何不同之處
關聯式資料庫環境（例如 DB2、Oracle 和 SQL Server）的依賴關係分析遵循一套成熟的流程。首先解析應用程式程式碼中的 SQL 語句，識別表和列的引用，建立程式存取表的映射圖，然後利用該映射圖確定遷移範圍和順序。整個流程結構清晰明確，依賴關係在 SQL 程式碼中一目了然。
IMS依賴性分析在各方面都更加複雜。
此結構是層級式的，而非關係式的。 IMS資料庫以段類型樹的形式組織，其中每個段類型都有明確的父子關係。從IMS資料庫讀取患者記錄的COBOL程式無法執行。 SELECT * FROM PATIENTS WHERE ID = ?它首先呼叫 Get Unique (GU) 來遍歷層次結構到達根段，然後呼叫 Get Next Within Parent (GNP) 來遍歷子段。該程式的依賴項並非某個表，而是遍歷層次結構中的特定路徑。更改該結構可能會導致程式崩潰，而這種崩潰是任何 SQL 層級的分析都無法偵測到的。
這些依賴關係分佈在三個不同的結構中。要全面了解 COBOL 程式如何使用 IMS，需要分析以下內容：
- DBD（資料庫描述符）： 定義物理段層次結構、鍵字段、存取方法（HDAM、HIDAM、HISAM、HSAM）以及任何二級索引或邏輯關係
- PSB（程式規格區塊）： 定義程式被允許存取哪些資料庫，透過哪些PCB，以及具有哪些靈敏度和意圖規範。
- COBOL原始碼： 包含實際的 DL/I 調用，這些調用決定了要存取哪些區段、使用哪些調用函數、按什麼順序以及使用哪些 SSA。
任何單一資料來源都無法提供完整的資訊。僅讀取 COBOL 原始碼的分析只能看到呼叫類型和區段名稱，而無法了解實體資料庫結構。僅讀取 DBD 和 PSB 的分析只能看到程式被允許執行的操作，而無法了解程式實際執行的操作。
導航依賴位置。在關聯式資料庫中，每一行都可以透過鍵獨立尋址。而在IMS中，程式在層次結構中的目前位置會影響後續呼叫的回傳值。 GN（取得下一個）呼叫會傳回程式目前位置之後層次結構中的下一個區段。這種依賴性不僅取決於段的類型，還取決於到達目前位置的遍歷路徑。依賴IMS隱式層次排序的程式存在一種依賴性，而當資料遷移到關聯式資料庫（關聯式資料庫不保證等效的排序）時，這種依賴性就會消失。
DL/I 呼叫清單：COBOL 原始碼揭示了什麼
最直接有效的遷移前分析是對每個存取IMS的COBOL程式中的所有DL/I呼叫進行完整清點。這份清點清單能夠告訴遷移團隊每個程式實際上如何使用IMS，而不是它被允許使用IMS ...
COBOL 中的 DL/I 呼叫有兩種形式：
科博爾
* Form 1: EXEC DLI interface (CICS-compatible, high-level syntax)
EXEC DLI
GU DB2PCB
SEGMENT(CUSTROOT)
WHERE(CUSTID = WS-CUST-ID)
END-EXEC
* Form 2: xxxTDLI call interface (batch programs, assembler-compatible)
CALL 'CBLTDLI' USING WS-FUNCTION-CODE
PCB-CUSTOMER
WS-CUSTOMER-SEGMENT
WS-SSA-CUSTOMER兩種形式都包含相同的分析資訊：功能代碼、所使用的PCB、目標段，以及可選的限定調用的SSA（段搜尋參數）。完整的DL/I呼叫清單會從每個程式中提取所有這些資訊。
功能代碼分類及其遷移意義
DL/I 函數程式碼是每次呼叫中對遷移影響最大的元素。每個函數代碼都代表不同的資料存取模式，必須在目標關係資料庫中複製：
只讀函數： GU取得唯一值：使用限定的 SSA 直接導覽到某個段落。這相當於關聯式資料庫中帶有 WHERE 子句的 SELECT 語句。如果段鍵能夠清楚地對應到關係主鍵，則遷移過程非常簡單。
GN取得下一個：依層級順序移動到下一個段。此函數程式碼沒有直接的關係等效項，它依賴IMS的位置狀態和隱式排序。大量使用GN的程式需要仔細分析它們所依賴的排序方式。
GNP取得父級下的下一個子級：檢索目前父級段的後續子級。等效於獲取外鍵關係中的所有行。通常可以很好地對應到具有外鍵 WHERE 子句的 SELECT 語句。
保持功能（更新的前提條件）： GHU, GHN, GHNP取得與 GU、GN、GNP 等效的 Hold 操作。 「hold」標誌表示接下來將執行更新 (REPL) 或刪除 (DLET) 操作。使用 hold 呼叫的程式是讀取-修改-寫入程式；遷移必須在 hold 操作和後續更新操作之間保持事務完整性。
更新功能： ISRT插入：新增一個新的段。等價於 INSERT。 DLET刪除：移除目前持有的段及其所有依賴段。 「所有依賴段」行為是IMS特有的級聯操作，必須在目標系統中明確實現。 REPL替換：使用新資料更新目前持有的段。等效於 UPDATE。
這對於遷移範圍至關重要：僅呼叫 GU 和 GNP 的程式是 IMS 資料的唯讀使用者，遷移風險較低，驗證也更簡單。而使用 GHU、REPL 和 DLET 的程序是事務處理程序，會修改層級結構；其遷移需要保持事務完整性，而 IMS 目前以原子方式強制執行這些操作。
導致每次遷移都失敗的三種依賴類型
邏輯關係
IMS 邏輯關係連接兩個物理上分離的資料庫中的段。資料庫 A 中的邏輯子段在資料庫 B 中有一個邏輯父段。當 COBOL 程式遍歷邏輯關係時，它會沿著一條物理上跨越資料庫邊界的路徑進行操作。 IMS 會透明地管理這種遍歷，但當資料庫獨立遷移時，這種遍歷就會消失。
邏輯關係是IMS遷移中風險最高的依賴類型，原因在於：它們在COBOL原始碼中是看不見的。 COBOL程式呼叫GNP來取得段的子段。 GNP調用的是物理父子關係還是邏輯關係，是由PSB和DBD決定的，而不是COBOL程式碼。如果遷移團隊只分析COBOL原始碼，就無法得知GNP呼叫是否跨越了邏輯關係邊界，除非單獨分析PSB和DBD。
使用邏輯關係的程式需要遷移以在目標系統中複製邏輯關係的語義（通常是關係模型中的 JOIN），並驗證使用該關係的每個程式都能從其從 IMS 邏輯遍歷收到的 JOIN 中獲得等效結果。
二級索引資料庫
IMS 二級索引資料庫提供了一條存取主資料庫的備用路徑，允許程式透過除根鍵之外的欄位檢索資料段。二級索引資料庫是一個獨立的 IMS 資料庫，擁有自己的資料庫定義域 (DBD)，但其資料來自主資料庫。
遷移團隊經常在分析階段而不是規劃階段發現輔助索引資料庫，原因如下：
- 它們在資料庫定義域 (DBD) 中定義，但這些資料庫定義域並不總是與主資料庫定義域 (DBD) 分組在一起。
- 使用二級索引的程式會在其程式服務公告 (PSB) 中指定索引資料庫，但透過二級索引導航到主資料庫的程式可能不會在 COBOL 原始程式碼中明確地表明這一點。
- 文件可能只描述主資料庫，而不提及它的二級索引。
如果程式透過二級索引存取 IMS，則其存取模式依賴關係必須在目標系統中以非主鍵索引或不同的查詢策略進行複製。如果在遷移過程中遺漏此依賴關係，程式雖然可以運行，但找不到所需的記錄。
GSAM資料庫
GSAM（通用順序存取方法）資料庫是IMS用於順序批次的接口，它本質上允許COBOL批次程式使用DL/I呼叫來實現功能上的順序檔案I/O。 GSAM資料庫沒有段層次結構；它們是扁平的順序結構，透過IMS訪問，從而利用IMS的恢復和重新啟動功能。
使用 GSAM 資料庫的程序是批次程序，其復原行為依賴 IMS 的檢查點/重新啟動支援。遷移必須保留此復原行為，或將其替換為目標平台上的等效機制。
建立遷移前依賴關係清單
完整的 IMS 依賴性分析會產生六項交付成果，這些成果共同定義了遷移範圍、風險和順序。
交付成果 1：PCB 到資料庫映射
每個 PSB 中的每個 PCB 都會對應到一個特定的 DBD（特定的 IMS 資料庫）。列出所有 PSB 中的每個 PCB 並將其對應到其對應的 DBD，即可產生權威的程式存取資料庫權限清單。這是理解權限範圍的起點，但它誇大了實際的依賴關係，因為程式可能擁有包含比其實際使用的資料庫更多的 PSB。
交付成果 2：各專案實際通話量
解析每個 COBOL 程式的 DL/I 調用，即可產生實際使用清單：每個程式實際調用了哪些 PCB，使用了哪些功能碼，存取了哪些段類型，以及使用的是限定段鍵存取 (SSA) 還是非限定導航（位置遍歷）。這使得權限範圍從 PSB 定義的權限縮小到實際的程式行為。
交付成果3：邏輯關係使用圖
透過將呼叫清單與資料庫定義檔 (DBD) 進行交叉比對，可以確定哪些程式的 GNP 或 GN 呼叫跨越了邏輯關係。這不僅需要分析 COBOL 原始碼和程式服務業務文件 (PSB)，還需要分析 DBD 結構，因為 DBD 結構定義了哪些父子關係是物理性的，哪些是邏輯的。
交付成果 4：二級索引使用圖
在程式服務聲明 (PSB) 中指定二級索引資料庫或發出包含引用非根鍵欄位的二級索引請求 (SSA) 的呼叫的程序，均被認定為二級索引使用者。此映射表記錄了存在的二級索引、它們支援的主資料庫以及依賴它們的程式。
交付成果 5：每個資料庫的呼叫類型分佈
對於每個納入研究範圍的IMS資料庫，所有存取該資料庫的程式中呼叫類型的分佈顯示了其遷移的複雜性：
- 僅透過讀取功能（GU、GN、GNP）存取的資料庫更容易遷移。
- 透過保持功能和更新（GHU + REPL、GHN + DLET）存取的資料庫需要事務完整性複製。
- 高GN使用率的資料庫表示存在位置導航依賴關係，需要進行排序分析。
- 具有邏輯關係的資料庫需要在目標資料庫中支援跨資料庫 JOIN 語意。
交付成果 6：專案風險分類
利用呼叫類型分佈和依賴類型清單，對每個程式進行遷移風險分類：
僅使用 GU 和 GNP 且具備合格 SSA 資格、存取單一資料庫且無邏輯關聯、無暫停/更新作業的程序，是早期遷移風險最低的候選程序。廣泛使用 GN、透過邏輯關聯存取多個資料庫或執行複雜暫停/更新操作的程序，是風險最高的程序，需要在遷移前進行最徹底的分析和驗證。
分析結果對移民規劃有何改變
依賴性分析不僅記錄現有事物，也會改變後續的決策。
遷移順序決定。透過邏輯關係共享 IMS 資料庫的程式不能獨立遷移。如果程式 A 讀取的邏輯子段與程式 B 的根段位於相同資料庫中，則在不遷移 B 的情況下遷移 A（或建立橋接）會導致 A 損壞。依賴關係圖決定哪些程式必須一起遷移。
目標設計決策。呼叫類型分佈決定了目標關係模式的結構。僅透過鍵限定的 GU 和 GNP 呼叫存取的層級父子關係，可以清楚地轉換為目標中的外鍵關係。而透過具有位置依賴關係的 GN 呼叫存取的相同關係，則要求目標模式保留等效的順序，可以透過明確 ORDER BY 子句、序列欄位或其他實現相同結果的存取模式來實現。
驗證範圍的確定。分析旨在識別哪些程式是IMS資料的唯讀使用者，哪些是事務處理器。只讀程序可以透過比較原始IMS系統和遷移後系統的輸出結果進行驗證。事務處理器需要進行交易等效性測試，以確保對目標系統執行相同的操作序列會產生與原始系統相同的資料狀態變更。
風險分類。邏輯關係和輔助指標分析是風險分類的主要依據。每個遷移項目都有一個風險登記冊。 IMS依賴性分析會告訴團隊應該在登記冊中新增哪些條目。
SMART TS XL 執行IMS依賴性分析
SMART TS XL“ 靜態程式碼分析 解析每個 COBOL 程式的 DL/I 調用，包括 EXEC DLI 和 xxxTDLI 調用介面形式，並從中提取每個調用的功能碼、PCB 引用、段名稱和 SSA 結構。這樣，無需運行 IMS 系統或進行人工程式碼審查，即可產生整個 COBOL 產品組合中程式層級的實際呼叫清單。
應用程式依賴關係映射將此清單擴展為跨程式依賴關係圖：哪些程式共用對哪些 IMS 資料庫的存取權限，哪些程式使用相同的 PCB，哪些程式的存取模式有重疊，需要進行協調遷移。當邏輯關係連接跨資料庫的段時，依賴關係映射會將這種跨資料庫連接表示為必須在目標系統中保留的明確關係。
影響分析功能可以解答每個遷移團隊在轉換任何資料庫之前都必須回答的問題：如果遷移此 IMS 資料庫，哪些程式會受到影響？哪些存取模式需要複製？以及需要驗證哪些測試案例以確認等效性？答案並非估算值，而是基於實際 DL/I 呼叫清單產生的列舉清單。
JCL擴充功能增加了操作上下文：哪些 JCL 作業步驟會呼叫哪些程式存取 IMS，呼叫順序為何，以及使用哪些 PSB 規格。操作依賴鏈（即透過多個程序處理 IMS 資料的批次作業序列）與程序級存取模式對於遷移規劃同樣重要。如果只遷移資料庫而不遷移圍繞它的批次作業編排，則系統在隔離環境中可以正確處理記錄，但在生產環境中執行時，作業序列會出錯。
對於進行 遺產現代化 IMS支持的系統中，由以下因素產生的結構證據 SMART TS XL 這是後續所有遷移決策的輸入：哪些程式在哪一波遷移，哪些資料庫可以獨立轉換，哪些需要協調轉換，哪些存取模式需要重新架構而不是直接轉換。正如在以下上下文中所述： 將 IMS 和 VSAM 結構與 COBOL 程式一起遷移COBOL 程式與遺留資料結構之間的相互連結意味著資料遷移和程式碼分析必須並行進行，依賴關係清單是使平行規劃成為可能的機制。
庫存並非遷移
IMS依賴性分析能夠產生知識。遷移仍然需要決策、工程設計和驗證。分析改變的是決策的品質、工程範圍的完整性、以及驗證的可靠性。
成功遷移IMS資料庫的組織並非那些擁有最迫切的遷移計畫或最大遷移預算的組織。他們是那些在遷移之前就對自身資料庫瞭如指掌的組織，包括訪問每個資料庫的每個程序、揭示每個程序訪問模式的每個函數代碼、創建跨數據庫依賴關係的每個邏輯關係，以及提供訪問路徑的每一個二級索引——如果沒有明確複製，這些訪問路徑在遷移過程中將無法保留。
這種知識並非來自文檔，而是來自程式碼解析。
