データ移行は単独では実行できず、データセットの読み書きを行う COBOL アプリケーションと並行して進化する必要があります。この制約こそが、VSAM の近代化における最大の課題です。VSAM (Virtual Storage Access Method) は単なるファイル形式ではありません。それはプログラム間のデータ契約であり、FD エントリと SELECT 句以外ではどこにも定義されていない暗黙の仕様であり、企業システム内のすべてのプログラムが最も重要なビジネスデータをどのように生成および消費するかを規定します。レコードレイアウトの変更が、そのレコードを読み取るすべてのプログラムに反映されないと、データ破損が発生し、消費するプログラムが想定していた意味を持たなくなったデータに基づいて規制報告書が実行されるまで、その破損が表面化しない可能性があります。
VSAMデータの近代化に成功する組織は、ターゲットスキーマから始める組織ではありません。VSAMファイルに何が含まれているか、どのように構造化されているか、どのプログラムがどのようなパターンでアクセスしているか、そしてプロデューサーとコンシューマーの間にどのような暗黙の契約が存在するかといったことを、証拠に基づいて完全に理解することから始める組織です。この理解、つまりVSAMファイル構造分析は、その後のすべての決定の前提条件となります。どのVSAMデータセットをリレーショナルテーブルにマッピングするか、どのデータセットに異なるターゲットアーキテクチャが必要か、どのレコードレイアウトに精度を維持するデータ型変換が必要か、そしてどの共有データセットを個別にではなく協調した単位として移行する必要があるか、といった決定です。
VSAMを構成する4つの組織と、それぞれの組織が求める要件
VSAMデータセットは4つの異なる構成で存在します。それぞれ構造特性、典型的なアクセスパターン、そして最新のターゲットアーキテクチャへの自然なマッピングが異なります。すべてのVSAMデータセットを同一に扱い、一括してリレーショナルテーブルに変換すると、一部のデータセットでは正常に動作するものの、他のデータセットではパフォーマンスが低下したり、機能的に失敗したりするターゲットが生成されます。
KSDS（Key-Sequenced Data Set）は、最も一般的なVSAM構成です。レコードは主キー（プライムキー）によって物理的に順序付けられ、キーによる直接アクセスとキー順のシーケンシャルアクセスの両方が可能になります。KSDSファイルには、オプションで代替インデックス（主キー以外のフィールドによる検索を可能にするセカンダリキーパス）を設定できます。KSDSの最適な対象はリレーショナルテーブルであり、主キーがプライマリキーとなり、代替インデックスがSQLインデックスとなります。
ESDS（Entry-Sequenced Data Set）は、レコードを書き込んだ順序で格納します。キーはなく、レコードは物理的なバイトオフセット（RBA：相対バイトアドレス）で参照されます。ESDSファイルは通常、監査証跡、トランザクションジャーナル、イベントストリームなどのログのようなデータに使用されます。ESDSの最適な格納先は、データを利用するプログラムがどのようにデータにアクセスするかによって、追記専用のリレーショナルテーブル、イベントストリーム（Kafkaトピック）、または時系列データベースとなります。
RRDS（相対レコードデータセット）は、相対レコード番号でアドレス指定される固定長レコードを格納します。ファイル内の各スロットはレコード番号に対応し、スロットは空（削除済み）にすることができます。RRDSファイルは、レコード番号がアプリケーションにとって意味を持つ直接アクセスシナリオで使用され、多くの場合、単純なルックアップテーブルやハッシュベースのストレージとして利用されます。理想的なターゲットは、数値シーケンス識別子を持つリレーショナルテーブル、またはデータセットが小さくアクセス頻度が高い場合はインメモリルックアップ構造です。
LDS（Linear Data Set）は、バイト単位でアドレス指定可能なストレージであり、VSAMからはレコード構造が見えません。これは、VSAMのバイト範囲内で独自の内部フォーマットを管理するアプリケーション（通常はDB2、Javaワークロード、またはカスタムプログラム）によって使用されます。LDSファイルは標準のCOBOLファイルディスクリプタでは解析できず、その構造は書き込みを行うアプリケーション層にのみ存在します。
各データセットの分析結果には、どの組織を使用しているかが明記されていなければなりません。なぜなら、組織によって、ターゲットアーキテクチャ、アクセスパターン、構造を理解するために必要な具体的な分析など、その後のあらゆる要素が決定されるからです。
レコードレイアウト解析の問題
レコードのレイアウトは、VSAM構造解析において最も分析的に複雑な側面です。リレーショナルスキーマでは、すべての列に定義された型、名前、およびデータベースエンジンによって強制される制約がありますが、VSAMレコードには自己記述的な構造がありません。レイアウトは完全にCOBOL FDエントリ内に存在し、FDエントリは単純なものはほとんどありません。
FDエントリーとコピーメンバー
VSAMデータセットのレコード構造は、COBOLデータ部（DATA DIVISION）のファイル記述（FD）エントリで定義されます。適切に管理されたコードベースでは、FDエントリはCOPYメンバーを参照します。COPYメンバーは、レコードレイアウトを定義する共有コピーブックであり、データセットにアクセスするすべてのプログラムによってインクルードされます。
COBOL
FILE SECTION.
FD CUSTOMER-FILE
LABEL RECORDS ARE STANDARD
RECORD CONTAINS 250 CHARACTERS.
01 CUSTOMER-RECORD.
COPY CUSTMSTR.コピーメンバー CUSTMSTR 実際のフィールドレイアウトを定義します。47 プログラムが含まれる場合 CUSTMSTRすると、47個のプログラムが、それが定義するレコードレイアウトへの依存関係を共有します。 CUSTMSTR 47個すべてのプログラムに影響します。これは、データに適用されたコピーブック結合問題です。VSAMレコードレイアウトは共有依存関係であり、それを使用するすべてのプログラムを調整せずに変更することはできません。
移行分析においては、すべてのFDエントリをそのコピーブックまで追跡し、すべてのコピーブックをそれをインクルードするすべてのプログラムにマッピングする必要があります。共有レイアウトの依存関係グラフは、移行範囲を理解するための基盤となります。
再定義：複数のレイアウト、1つのレコード
その REDEFINES VSAMレコードの解析が真に複雑になるのは、この句においてです。REDEFINESは、同じ物理ストレージ上に異なるフィールド解釈を重ね合わせることを可能にします。トランザクションタイプコードを含むVSAMレコードは、そのコードに応じて残りのバイトを異なる方法で解釈するためにREDEFINESを使用する場合があります。
COBOL
01 TRANSACTION-RECORD.
05 TXN-TYPE PIC X(2).
05 TXN-COMMON-DATA PIC X(48).
05 TXN-DETAIL REDEFINES TXN-COMMON-DATA.
10 TXN-PAYMENT.
15 PAY-AMOUNT PIC S9(11)V99 COMP-3.
15 PAY-CURRENCY PIC X(3).
15 PAY-METHOD PIC X(2).
15 FILLER PIC X(28).
05 TXN-WITHDRAWAL REDEFINES TXN-COMMON-DATA.
10 WDR-AMOUNT PIC S9(11)V99 COMP-3.
10 WDR-ACCOUNT PIC 9(12).
10 WDR-BRANCH PIC 9(5).
10 FILLER PIC X(18).このレコードにはレイアウトが 1 つではなく 3 つあります。 TXN-TYPEターゲットリレーショナルスキーマでは、通常、ポリモーフィックテーブル設計（各バリアントごとにNULL許容列を持つ単一幅テーブル）、正規化設計（親行と型固有の子行）、またはバリアントデータを保持するJSON列のいずれかが必要になります。これらの決定は、分析なしにはできません。 TXN-TYPE データ内に値が存在し、REDEFINES バリアントが実際に使用されている。
完全なレコードレイアウト分析には、以下のことが必要です。
- すべてのFDエントリ内のすべてのREDEFINES階層を特定します。
- どのREDEFINESバリアントがどの条件下でアクティブになるかを判断する（関数従属性解析だけでなく、プログラムロジック解析も必要）。
- 各バリアントのフィールドタイプ、長さ、およびパック10進精度を文書化する
- 対象スキーマに適した正規化戦略を推奨する
COMP-3と数値精度
COBOLの PIC S9(11)V99 COMP-3 （パック10進数）は、SQL標準データ型には直接対応するものがない特定の精度とスケール特性を持っています。 V 小数点が暗黙的に含まれていることを示し、値は暗黙的に小数点以下2桁の整数として格納されます。 COMP-3 1バイトあたり2桁の10進数を格納する。最後の0.5バイトには符号が含まれる。
このフィールドをリレーショナルデータベースに移行する場合、正しいSQLターゲットは DECIMAL(13, 2)はなく、 FLOAT丸め誤差が生じるため、 INTEGERこれによって小数点以下の桁数が失われます。COMP-3 フィールドに金額が格納される金融システムでは、精度要件は譲歩できません。 PIC S9(11)V99 COMP-3 ターゲットスキーマで浮動小数点型に変換すると、バッチ実行全体で蓄積される丸め誤差が発生し、規制報告に影響を与える可能性があります。
ターゲットスキーマの設計を開始する前に、すべてのFDエントリのすべてのCOMP-3フィールドについて、その正確な精度、スケール、および符号規則を文書化する必要があります。
COBOLソースコードにおけるVSAMアクセスパターンの分析
FDエントリはレコードの内容を表します。COBOL PROCEDURE DIVISIONはプログラムがレコードをどのように使用するかを表します。完全な構造分析には、どちらも必要です。アクセスパターン分析では、データセットにアクセスするすべてのプログラムのすべてのファイルアクセス動詞を調べます。
SELECT句：最初のシグナル
ENVIRONMENT DIVISION の SELECT 句は、COBOL プログラムが VSAM ファイルにアクセスする方法を定義します。
COBOL
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT CUSTOMER-FILE
ASSIGN TO CUSTFILE
ORGANIZATION IS INDEXED
ACCESS MODE IS DYNAMIC
RECORD KEY IS CUST-PRIME-KEY
ALTERNATE RECORD KEY IS CUST-ALT-KEY
WITH DUPLICATES
FILE STATUS IS WS-CUST-STATUS.このSELECT句は以下を明らかにします。
ORGANIZATION IS INDEXED→ KSDSACCESS MODE IS DYNAMIC→ このプログラムはシーケンシャルアクセスとランダムアクセスの両方を使用しますALTERNATE RECORD KEY IS CUST-ALT-KEY WITH DUPLICATES→ 代替インデックスが存在し、このプログラムはそれを使用します
動的アクセスモードは特に重要です。動的モードでKSDSにアクセスするプログラムは、 READ 直接アクセス用のキーと READ NEXT 指定された位置からのシーケンシャルスキャンの場合。これらのアクセスパターンは両方ともターゲット側で再現する必要があり、リレーショナルスキーマでは直接ルックアップ（主キークエリ）と範囲スキャン（順序付きトラバーサル）の両方のサポートが必要になる場合があります。
アクセス動詞とその移行への影響
ファイルアクセス動詞はそれぞれ、プログラムがVSAMデータセットとどのようにやり取りするかの異なる側面を明らかにします。
読む（直接）： READ CUSTOMER-FILE KEY IS WS-CUST-KEY、直接キー検索。 SELECT ... WHERE primary_key = ?ほとんどのKSDSプログラムはこのパターンを使用しており、これはリレーショナルインデックスによるルックアップに直接変換されます。
読み込み（順次）： READ CUSTOMER-FILE NEXT RECORD現在位置からのシーケンシャルスキャン。 SELECT ... ORDER BY primary_key カーソル位置決め機能付き。暗黙的な順序依存性、つまりシーケンシャル処理のためにVSAMの自然なキー順序に依存するプログラムは、ターゲットで明示的に保持されなければなりません。
開始： START CUSTOMER-FILE KEY >= WS-SEARCH-KEY 続い READ NEXT部分的なキー位置からの範囲スキャン。範囲クエリにマッピングされます。 SELECT ... WHERE primary_key >= ? ORDER BY primary_keySTART を使用するプログラムは、シーケンシャル スキャンの下限を設定します。これは、ターゲット テーブルが同じキー順序でない限り、単純な同等のパターンがない KSDS ファイルにとって重要なアクセス パターンです。
書く： キーによって新しいレコードを挿入します。 INSERT INTOVSAM ファイルに代替インデックスがある場合、書き込みはそれらのインデックスとの整合性を維持する必要があります。VSAM ではこれは自動的に行われますが、リレーショナル データベースでは、同等のセカンダリ インデックス テーブルを維持するために、データベース トリガーまたはアプリケーション レベルのコードが必要です。
リライト： レコードをその場で更新します。レコードは現在保持されている必要があります（保持意図付き読み取り後）。 UPDATE ... WHERE primary_key = ?REWRITEは読み取り・変更・書き込みのパターンであり、移行では読み取りと書き込みの両方でトランザクションの整合性を維持する必要があります。
DELETE:キーを指定してレコードを削除します。KSDS ファイルでは、DELETE は物理的な削除です。削除されたスロットが以降のシーケンシャル スキャンで使用できなくなることを想定しているプログラムは、この物理的な削除動作に依存しています。ターゲットのソフト削除 (論理削除フラグ) は、使用するすべてのプログラムが論理的に削除されたレコードをフィルタリングするように更新されない限り、同等の動作を生み出しません。
代替インデックスの使用法：隠れた依存関係
KSDSファイル上の代替インデックスは、VSAM移行において最も見落とされがちな依存関係の一つです。代替インデックスを使用すると、プログラムは主キー以外のフィールドでKSDSにアクセスできます。代替インデックス自体は独立したVSAMデータセット（PATH）であり、ベースクラスタと同期を保つ必要があります。
アクセスするプログラム CUSTOMER-FILE 代替キーを通して CUST-ALT-KEY ベースクラスタのFDエントリのみを解析した場合、見えない依存関係が存在します。移行には以下が必要です。
- どのプログラムがどの代替キーを使用しているか（SELECT句で確認可能）を特定します
ALTERNATE RECORD KEY宣言） - 各代替キーを対象テーブルの対応するSQLインデックスにマッピングします。
- 対象テーブルに対するINSERTおよびDELETE操作が、代替インデックスと同等の機能を自動的に維持するようにします。これは通常、データベースエンジンが透過的に維持するSQLの一意または非一意インデックスによって実現されます。
分析では、すべてのKSDSデータセットについて、すべての代替インデックスを列挙し、それぞれをそのインデックスを使用するプログラムにマッピングする必要があります。
共有データセットの問題：暗黙のデータ契約
VSAMファイルは、複数のプログラムや複数のJCLジョブステップ間で頻繁に共有されます。この共有によって、コード自体の中にしか存在しない、レコードのレイアウト、キー範囲、アクセスパターンに関するプログラム間の暗黙のデータ契約、つまり合意が形成されます。
共有データセットの依存関係には2つの側面がある。
プロデューサー・コンシューマー関係。プログラムAは、プログラムBが読み取るレコードを書き込みます。プログラムAが生成するレコードのレイアウト、キー値、および順序は、プログラムBが消費することを想定しているものと完全に一致する必要があります。AとBが共有データ契約を調整せずにそれぞれ異なるターゲットスキーマに個別に移行されると、結果としてサイレントデータ破損が発生します。つまり、Bによるターゲットデータベースへの読み取りは成功しますが、Bのロジックが正しく処理できない形式でデータが返されます。
ジョブステップ間での同時アクセス。JCLジョブストリームは複数のステップで構成され、各ステップは同じVSAMデータセットに対して異なるプログラムを順番に実行します。ステップ1は書き込み、ステップ2は読み取りと変換を行い、ステップ3は結果を書き込みます。移行ではこの順序依存性を維持する必要があり、プログラムが共有データセットにアクセスして変更する順序は、システムの動作仕様の一部です。
完全な共有データセット分析には、以下の条件が必要です。
- すべてのVSAMデータセットと、それにアクセスするすべてのプログラムを列挙します。
- 各プログラムのアクセスを、プロデューサー（書き込み/書き換え/削除）、コンシューマー（読み取り）、またはその両方に分類してください。
- 各プログラムが実行されるJCLジョブコンテキスト、どのステップ、どのジョブ、どのスケジューラ依存関係チェーンで実行されるかを文書化する。
- 生産者の出力形式が消費者の期待する入力形式と完全に一致する必要がある生産者と消費者のペアを特定する。
この分析は、単一のプログラムを単独で調べるだけではできません。プログラム間、JCL間を横断する構造分析が必要です。
移行前の成果物：分析で作成すべきもの
データ近代化計画に十分なVSAM構造分析では、以下の6つの成果物が得られます。
成果物1：VSAMデータセットインベントリ
環境内のすべての VSAM データセットについて、データセットの構成 (KSDS/ESDS/RRDS/LDS)、平均および最大レコード長、推定レコード数 (JCL SPACE パラメーターまたはカタログエントリから取得)、キー構造 (主キーのオフセット、長さ、代替キー構造)、およびデータセットに代替インデックスがあるかどうかを示します。
成果物2：レコードレイアウトカタログ
各データセットについて、すべての FD エントリとそれが参照するコピーブック、REDEFINES 階層を含むすべてのフィールド定義、正確な精度とスケールを持つすべての COMP-3 フィールド、バイト長を持つすべてのバイナリ (COMP/COMP-5) フィールド、制御フィールドを持つすべての可変長要素 (OCCURS DEPENDING ON)、および REDEFINES によって暗示されるすべての条件付きまたはレイアウト バリアントが含まれます。
成果物3：プログラムごとのアクセスパターン分類
各データセットにアクセスするすべてのプログラムについて、SELECT句の特性（構成、アクセスモード、代替キーの使用）、使用されるアクセス動詞の完全なセット（READ/START/WRITE/REWRITE/DELETE）、プログラムがシーケンシャルアクセスを使用し、キーの順序に依存するかどうか、プログラムが使用する代替インデックス、およびプログラムが読み取り-変更-書き込みパターン（暗黙のトランザクション要件）を持つかどうか。
成果物4：共有データセットマップ
ノードがVSAMデータセットとプログラム、エッジがアクセス関係とそのタイプ（読み取り/書き込み）を表す有向グラフ。このグラフには、すべてのプロデューサー、すべてのコンシューマー、プロデューサーとコンシューマーのペア、および各アクセスに対応するJCLジョブシーケンスコンテキストが表示されます。
成果物5：ターゲットスキーマに関する推奨事項
各VSAMデータセットについて、その構成とアクセスパターンに基づいた推奨ターゲットアーキテクチャ：
| VSAMタイプ | プライマリアクセスパターン | 推奨ターゲット |
|---|---|---|
| KSDS、直接キーアクセスのみ | 主キーによるポイントルックアップ | 関係テーブル、インデックス付き |
| KSDS、開始/次を読む | 範囲スキャン（キー順） | クラスタ化インデックスを持つリレーショナルテーブル |
| 代替インデックス付きKSDS | マルチパスキーアクセス | 複数のインデックスを持つリレーショナルテーブル |
| ESDS、追記専用 | 順次追加、キーなし | 追記専用のテーブル、イベントストリーム、またはログ |
| ESDS、RBAアクセス可能 | バイトオフセット位置決め | メタデータインデックス付きオブジェクトストレージ |
| RRDS | レコード番号へのアクセス | シーケンス列を持つリレーショナルテーブル |
| 大規模KSDS（バルク、分析） | 完全な連続スキャン | カラム型ストレージまたはデータレイク |
| LDS | アプリケーション管理内部フォーマット | アプリケーション層の分析が必要 |
成果物6：高精度フィールドレジストリ
すべてのデータセットにおけるすべてのCOMP-3、COMP、COMP-5、および浮動小数点フィールドについて、COBOL定義、正しいSQLデータ型マッピング、および移行前後にマッピングの精度検証が必要なフィールドを示すフラグ。
VSAM分析とリレーショナルスキーマ分析の違いとは？
リレーショナルデータベース間の移行経験を持つチームは、スキーマ移行の思考モデル（DDLを抽出し、スキーマを再設計し、データを移行する）を適用してしまうため、VSAMの分析を過小評価してしまうことがあります。VSAMには、データベース的な意味でのDDLは存在しません。スキーマは、ソースコード、FDエントリ、コピーブック、SELECT句、および特定のレコードに対してどのREDEFINESバリアントがアクティブになるかを決定するPROCEDURE DIVISIONロジックに分散されています。
VSAM分析を構造的に異なるものにしている3つの特性：
スキーマはコード内に存在します。VSAMデータセットのレコードレイアウトは、データベースカタログではなく、COBOLソースコードで定義されます。そのため、スキーマを見つけるにはソースコードを解析する必要があります。変更するには、コピーブックを共有するすべてのプログラムを調整する必要があります。また、すべてのバリエーションを理解するには、FDエントリだけでなく、プログラムロジックを分析する必要があります。
アクセスパターンはプログラムの動作に暗黙的に含まれています。リレーショナルデータベースは、EXPLAINプランとクエリログを通じてクエリパターンを公開します。VSAMのアクセスパターンは、ファイルにアクセスするプログラムのプロシージャ部でのみ確認できます。プログラムがキー順序、代替インデックスアクセス、または範囲スキャンに依存しているかどうかを理解するには、コード分析が必要です。
共有データセットは、隠れた契約を生み出します。リレーショナルデータベースでは、スキーマはデータベースレベルの成果物であり、すべての利用者が共有し、参照できます。VSAMでは、レコードレイアウトは各プログラムのコピーブックに埋め込まれています。2つのプログラムは、名目上は同じレコードレイアウトであっても、異なるコピーを持つ可能性があります。この相違を発見するには、単一のスキーマ定義を調べるのではなく、プログラム間でコピーブックの定義を比較する必要があります。
認定条件 SMART TS XL VSAM構造解析を実行します
SMART TS XLさん 静的コード分析 COBOLソースに存在するVSAM構造のすべての要素（FDエントリ、COPYメンバ展開、SELECT句宣言（組織、アクセスモード、主キーおよび代替キーの指定）、およびPROCEDURE DIVISION内のすべてのファイルアクセス動詞）を解析します。各VSAMデータセットについて、解析結果はアクセスパターン分類、完全なREDEFINES解決を含むレコードレイアウト、および精度メタデータを含むCOMP-3フィールドレジストリを生成します。
アプリケーション依存関係マッピングは、共有データセットマップを作成します。このマップには、各VSAMデータセットにアクセスするすべてのプログラムが、アクセスタイプ別に分類され、プロデューサーとコンシューマーの関係が特定され、コピーブックの共有グラフが解決されます。47個のプログラムがVSAMレコードレイアウトを定義するコピーブックを共有している場合、依存関係マップによって、レイアウト変更によって47個のプログラムが予期せぬ形で動作しなくなる前に、移行の決定を行う前に、47個すべてのプログラムが可視化されます。
JCL拡張機能は、運用コンテキストを提供します。つまり、どのJCLジョブステップが、DDステートメント内でどのVSAMデータセットを参照しているか、どのような順序で、どのジョブストリームで参照しているかがわかります。JCLジョブレベルで存在するプロデューサーとコンシューマーの関係（ステップ1がVSAMデータセットに書き込み、ステップ3がそれを読み取るなど）は、JCL依存関係分析で可視化され、バッチスケジュールによって強制される運用順序の依存関係を維持する移行シーケンスが可能になります。
影響分析機能は、VSAM移行の決定に先立つあらゆる疑問、すなわち「このデータセットのレイアウトが変更された場合、どのプログラムが影響を受けるか」という問いに答えます。移行作業を開始する前に、関連するコピーブックを共有するすべてのプログラム、データセットを参照するすべてのJCLステップなど、影響範囲が列挙されるため、影響を受けるプログラムを一つずつ発見していくのではなく、連携のとれた移行計画の基礎を築くことができます。
エンタープライズ検索機能により、近代化プログラム全体でVSAMインベントリ全体をクエリできるようになります。数百万行のCOBOLコードの中から、特定のVSAMデータセットにアクセスするすべてのプログラム、特定のレコードレイアウトを定義するすべてのコピーブック、START/READ NEXTパターン（順序依存関係を示す）を使用するすべてのプログラム、COMP-3として定義されているすべてのフィールド（精度を考慮したターゲットマッピングが必要）を数秒で見つけることができます。
文脈で説明されているように IMSおよびVSAMデータ構造をCOBOLプログラムと共に移行するそのため、データ移行とコード分析は並行して進める必要がある。 SMART TS XLVSAMの構造分析は、並列処理を扱いやすくするためのインベントリ、共有レコードのレイアウト、アクセスパターン、およびデータ移行を独立して実行できるか、プログラムの変更と調整する必要があるかを決定するプロデューサーとコンシューマーの関係を提供します。
理解できる構造こそが、移行可能な構造である
VSAMファイル構造解析は、近代化プログラムにおける単なるオーバーヘッドではありません。それは意思決定の基盤となるものです。レコードレイアウトのバリエーションを把握せずにターゲットスキーマを設計することはできません。プロデューサーとコンシューマーの関係を把握せずに移行の順序を決定することはできません。どのフィールドが小数点対応のターゲット型を必要とするかを把握せずにCOMP-3フィールドの精度を維持することはできません。
この分析を省略した近代化プログラムは、移行実行中に見落としていた問題に気づきます。例えば、分析されなかったREDEFINESバリアントによってターゲットに不正なレコードが生成されたり、共有データセットがすべてのコンシューマーと連携せずに移行されたり、VSAMのキー順序付けに依存する範囲スキャンが、クラスタ化インデックスで設計されていないターゲットテーブルから未定義の順序で結果を返したりする場合などです。実行中にこれらの問題が発覚すると、計画段階で分析を行った場合のコストの何倍もの費用が発生します。
まず構造を理解し、次にデータを移行する。この順序は形式的なものではない。正しい結果を生み出す移行と、最初の規制監査が実施されるまでは正しく見えるデータを生み出す移行との違いは、この順序にあるのだ。
