IMSデータベースの依存関係分析：移行前にモダナイゼーションチームが知っておくべきこと

IMSは、時代遅れという意味でのレガシーシステムではありません。大手銀行の売掛金管理、保険会社の保険契約管理、医療保険支払機関の請求処理などを支えるデータベースエンジンです。IBMは今もなお開発を続けています。問題はIMSが動作しなくなったことではなく、階層構造のセグメントツリーを熟知していた開発者が次々と退職し、IMSを基盤とするシステムに変更を加えるにはSQLを持たないデータモデルを理解する必要があり、IMSをリレーショナルデータベースのように扱う移行計画では必ずその違いに苦労することになる、という点です。

困難なケースとしては、移行の途中で、COBOLプログラムが単純なキー検索ではなく階層的な走査によってIMSにアクセスしていることに気づき、それをターゲットシステムで同等のナビゲーションロジックを用いて再現する必要があることが判明する場合や、2つの物理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レベルの分析では検出できない方法で、その構造をナビゲートするプログラムが動作しなくなる可能性があります。

依存関係は3つの異なる構造に分散しています。COBOLプログラムがIMSで行っていることの全体像を把握するには、以下の点を分析する必要があります。

• DBD（データベース記述子）： 物理セグメント階層、キーフィールド、アクセス方法（HDAM、HIDAM、HISAM、HSAM）、および二次インデックスまたは論理関係を定義します。
• PSB（プログラム仕様ブロック）： プログラムがどのデータベースに、どのPCBを介して、どの程度の機密性および意図仕様でアクセスできるかを定義します。
• COBOLソースコード： には、どのセグメントに、どの呼び出し関数を使用して、どの順序で、どのSSAを使用してアクセスするかを決定する実際のDL/I呼び出しが含まれています。

単一の情報源だけでは全体像を把握することはできません。COBOLソースコードのみを分析すると、呼び出しタイプとセグメント名はわかりますが、物理的なデータベース構造はわかりません。DBDとPSBのみを分析すると、プログラムに許可されている操作はわかりますが、実際にプログラムが実行する操作はわかりません。

ナビゲーションは位置に依存します。リレーショナルデータベースでは、すべての行はキーによって個別にアドレス指定できます。IMSでは、プログラムの階層内での現在の位置が、後続の呼び出しが返す値に影響します。GN（Get Next）呼び出しは、プログラムが現在いる場所から階層順序で次のセグメントを返します。この依存関係は、セグメントの種類だけでなく、現在の位置に至るまでのトラバーサルパスにも依存します。IMSの暗黙的な階層順序に依存するプログラムは、同等の順序が保証されないリレーショナルデータベースにデータを移行すると、この依存関係が解消されます。

DL/I コール インベントリ: COBOL ソースコードが明らかにするもの

移行前の分析で最も直接的に役立つのは、IMSにアクセスするすべてのCOBOLプログラムにおけるすべてのDL/I呼び出しの完全なインベントリを作成することです。このインベントリは、各プログラムがIMSに対して何を行っているかを移行チームに示します。これは、プログラムがIMSに対して何を行うことが許可されているか（PSBで定義されている）ではなく、実際に何を行っているかを示します。

COBOLにおけるDL/I呼び出しは、次の2つの形式で現れます。

COBOL

* 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に相当します。セグメントキーがリレーショナル主キーに適切にマッピングされる場合は、移行は簡単です。

GNGet Next: 階層的な順序で次のセグメントに移動します。これは、直接的な関係式に相当する機能コードがなく、IMS の位置状態と暗黙的な順序に依存しています。GN を多用するプログラムは、依存する順序を慎重に分析する必要があります。

GNP、Get Next Within Parent: 現在の親セグメントの次の子を取得します。外部キー関係にあるすべての行を取得することと同等です。通常、外部キーの WHERE 句を持つ SELECT にきれいにマッピングされます。

保持機能（更新の前提条件）： GHU, GHN, GHNPGU、GN、GNP に相当する Get Hold 関数。「hold」フラグは、更新 (REPL) または削除 (DLET) 操作が続くことを示します。hold 呼び出しを使用するプログラムは、読み取り・変更・書き込みを行うプログラムです。移行時には、hold とそれに続く更新の間でトランザクションの整合性を維持する必要があります。

更新機能: ISRT, Insert: 新しいセグメントの出現箇所を追加します。INSERT と同等です。 DLET, 削除: 現在保持されているセグメントとそのすべての依存セグメントを削除します。「すべての依存セグメント」の動作は、IMS固有のカスケードであり、対象システムで明示的に実装する必要があります。 REPLReplace: 現在保持されているセグメントを新しいデータで更新します。UPDATE と同等です。

これが移行範囲にとって重要な理由： GUとGNP呼び出しのみを使用するプログラムは、IMSデータの読み取り専用コンシューマーであり、移行リスクが低く、検証も容易です。一方、GHU、REPL、およびDLETを使用するプログラムは、階層構造を変更するトランザクション処理プログラムであり、その移行には、IMSが現在アトミックに強制している操作全体にわたるトランザクションの整合性を維持する必要があります。

あらゆる移行を阻害する3つの依存関係の種類

論理的関係

IMSの論理関係は、物理的に分離された2つのデータベースにまたがるセグメントを接続します。データベースAの論理子セグメントは、データベースBの論理親セグメントを持ちます。COBOLプログラムが論理関係を介してナビゲートする場合、物理的にデータベース境界を越えるパスをたどります。このトラバーサルはIMSによって透過的に管理されますが、データベースが個別に移行されると消滅します。

IMS移行において、論理関係が最もリスクの高い依存関係タイプとなる理由はただ一つ、COBOLソースコードからは見えないからです。COBOLプログラムは、セグメントの子を取得するためにGNPを呼び出します。このGNPが物理的な親子関係を辿るのか、論理関係を辿るのかは、COBOLコードではなく、PSBとDBDによって決定されます。COBOLソースコードのみを分析する移行チームは、PSBとDBDを別途分析しない限り、GNP呼び出しが論理関係の境界を越えていることを知る術がありません。

論理関係を使用するプログラムでは、移行によって、対象システムで論理関係のセマンティクス（通常はリレーショナルモデルにおけるJOIN）を再現し、その関係を使用するすべてのプログラムが、IMSの論理トラバーサルから受け取ったものと同じ結果をJOINから受け取ることを検証する必要があります。

二次索引データベース

IMSセカンダリインデックスデータベースは、プライマリデータベースへの代替アクセスパスを提供し、プログラムがルートキー以外のフィールドでセグメントを取得できるようにします。セカンダリインデックスデータベースは、独自のDBDを持つ独立したIMSデータベースですが、そのデータはプライマリデータベースから取得されます。

移行チームは、計画段階ではなく分析段階で二次インデックスデータベースを発見することが多い。その理由は以下のとおりである。

• これらは、必ずしもプライマリデータベースのDBDとグループ化されていないDBDで定義されます。
• セカンダリ インデックスを使用するプログラムは、PSB 内でインデックス データベースを指定しますが、セカンダリ インデックスを介してプライマリ データベースにアクセスするプログラムは、COBOL ソースコードでそれを明示しない場合があります。
• ドキュメントでは、セカンダリインデックスについて言及せずに、プライマリデータベースについてのみ説明している場合があります。

セカンダリインデックスを介してIMSにアクセスするプログラムは、アクセスパターンに依存しており、ターゲット側では非プライマリキーインデックスまたは別のクエリ戦略として複製する必要があります。移行時にこの依存関係が欠落すると、プログラムはエラーなく実行されますが、目的のレコードを見つけることができません。

GSAMデータベース

GSAM（Generalized Sequential Access Method）データベースは、IMSのシーケンシャルバッチ処理用インターフェースであり、COBOLバッチプログラムが機能的にシーケンシャルなファイルI/OにDL/I呼び出しを使用できるようにします。GSAMデータベースにはセグメント階層がなく、IMSを介してアクセスされるフラットなシーケンシャル構造であるため、IMSのリカバリ機能と再起動機能を利用できます。

GSAMデータベースを使用するプログラムはバッチプログラムであり、そのリカバリ動作はIMSのチェックポイント/再起動機能に依存しています。移行時には、このリカバリ動作を維持するか、ターゲットプラットフォームで同等のメカニズムに置き換える必要があります。

移行前の依存関係インベントリの構築

完全なIMS依存関係分析では、移行の範囲、リスク、および手順を定義する6つの成果物が生成されます。

成果物1：PCBとデータベースのマッピング

各PSB内のすべてのPCBは、特定のDBD（特定のIMSデータベース）に対応付けられます。すべてのPSBにわたるすべてのPCBを一覧表示し、それぞれを対応するDBDにマッピングすることで、どのプログラムがどのデータベースへのアクセスを許可されているかを示す公式リストが作成されます。これはスコープを理解するための出発点となりますが、プログラムが実際に使用するデータベースよりも多くのデータベースを含むPSBを持つ可能性があるため、実際の依存関係を過大評価してしまう可能性があります。

成果物2：プログラムごとの実際の通話記録

COBOLプログラムのすべてのDL/I呼び出しを解析すると、実際の使用リストが生成されます。つまり、各プログラムが実際にどのPCBを呼び出しているか、どの関数コードを使用しているか、どのセグメント型にアクセスしているか、そして修飾SSA（セグメントキーアクセス）を使用しているか、修飾されていないナビゲーション（位置走査）を使用しているかがわかります。これにより、PSBで定義された権限の範囲から、実際のプログラムの動作へと絞り込むことができます。

成果物3：論理関係使用マップ

呼び出しインベントリをDBDと相互参照することで、どのプログラムのGNPまたはGN呼び出しが論理的な関係をたどっているかを特定できます。これには、COBOLソースコードとPSBだけでなく、親子関係が物理的で、論理的であるかを定義する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ジョブステップが、どのプログラムを呼び出し、どの順序で、どのPSB仕様を使用してIMSにアクセスするかが明確になります。複数のプログラムを通してIMSデータを処理するバッチジョブシーケンスである運用依存関係チェーンは、プログラムレベルのアクセスパターンと同様に、移行計画において重要です。データベースを移行する際に、それを取り巻くバッチジョブオーケストレーションを移行しないと、単体ではレコードを正しく処理するシステムでも、ジョブシーケンスが実行される本番環境では失敗することになります。

実施するチーム向け レガシーの近代化 IMS が支援するシステムでは、 SMART TS XL これは、その後のすべての移行決定への入力となります。どのプログラムをどのウェーブで移行するか、どのデータベースを個別に変換できるか、どのデータベースを協調変換する必要があるか、どのアクセスパターンを直接変換するのではなく再設計する必要があるかなどです。 IMSおよびVSAM構造をCOBOLプログラムと並行して移行するCOBOLプログラムとレガシーデータ構造間の相互接続により、データ移行とコード分析は並行して進める必要があり、依存関係インベントリは並行計画を可能にするメカニズムです。

インベントリは移行ではない

IMSの依存関係分析は知識を生み出す。移行には依然として意思決定、エンジニアリング、検証が必要となる。分析によって変化するのは、意思決定の質、エンジニアリング範囲の網羅性、そして検証の信頼性である。

IMSデータベースの移行を成功させる組織は、最も厳しいスケジュールや最大の移行予算を持つ組織ではありません。移行を開始する前に、自社のデータベースがどのような状態にあるかを把握していた組織です。各データベースにアクセスするすべてのプログラム、各プログラムのアクセスパターンを明らかにするすべての関数コード、データベース間の依存関係を生み出すすべての論理関係、明示的なレプリケーションなしでは移行後に存続しないアクセスパスを提供するすべてのセカンダリインデックスなど、すべてを把握していた組織です。

その知識はドキュメントから得られるものではない。コードを解析することによって得られるものだ。