COBOLモダナイゼーションツールの多くは「プログラム」で止まっている。実際に移行が壊れるのは、それを呼び出す「バッチジョブ」の側だ。

すべてのテストに通過したのに、バッチウィンドウだけを外す移行

メインフレームのモダナイゼーションで繰り返し起きる失敗パターンの1つは、変換後のCOBOLがコンパイルできるかどうかや、与えられた入力に対して正しい出力を返すかどうかとは、実はまったく関係がない。システムは機能テストにすべて合格し、本番へ昇格し、それでも本番環境で処理ウィンドウ(処理時間枠)を外してしまう——原因は特定のプログラムが間違っているからではなく、ジョブがいつ・どのように実際に動いていたかを支配していた実行順序、チェックポイント/リスタートの挙動、バッチウィンドウの依存関係が、そもそも移行後のシステム設計に一度も引き継がれなかったからだ。これを早期に発見できるバッチ評価は、個々のプログラムロジックにとどまらず、ジョブストリーム、スケジューラの定義、先行・後続関係、異常終了(アベンド)処理といった、個々のプログラムより上位にある運用レイヤーまで検証範囲を広げているものだ。

その運用レイヤーには名前がある。そしてそれはCOBOLではない。JCLだ。

依存関係マップが通常見落としているもの

多くのCOBOLモダナイゼーションツールは、JCLを単なる足場——ジョブカードと、実行するプログラムや操作対象のファイルを指定するいくつかのEXEC文・DD文——として扱う。実際の依存関係グラフはCOBOL側(プログラム、コピーブック、CALL文)から構築され、JCLは「いつどのプログラムが動いたか」を示すメタデータ程度に縮小されてしまう。

その捉え方は、メインフレームの結合(カップリング)のかなりの部分が実際にどこに存在しているかを見落としている。JCLのシンボリックパラメータは、JCL展開(エクスパンション)を通して初めて解決され、単なる棚卸しスキャンでは未解決のテンプレート参照としてしか報告されないものを、ジョブストリームが実際に呼び出しているプログラムとして明らかにする必要がある。前段のジョブステップのリターンコードによって条件付きで実行されるJCLステップは、コード上では互いに一度も呼び出し合っていないプログラム同士の間に制御フロー上の結合を生み出す——そしてこの結合は、ドキュメントだけから構築された棚卸しでは一切見えない。数十のプログラムにまたがって共有されるコピーブックや、実行時に動的に解決されるCALLまで加えると、正直なところ、ほとんどのメインフレーム依存関係ドキュメントは「不完全」なのではなく、そもそもデフォルトで「間違っている」と言うべきだ。1つのCOBOLジョブが送金を行い、コンプライアンスチェックを発火させ、十数件の下流レポートを更新することもある——そのうちどれが実際に発生するかは、3ステップ前に設定された1つの条件コードだけに完全に左右されることがある。

Generation Data Group(GDG)はこの問題をさらに拡大する。GDGは「そのファイル」を直接指すのではなく、独自の保持・クリーンアップルールを持つローリング形式のデータセットファミリーの、相対世代または絶対世代を指す。モダナイゼーション向けプラットフォームは、この意味を単一の静的なファイル参照へ平坦化してしまわずに正しく引き継ぐためだけに、専用のサポートを構築せざるを得なかったほどだ。GDGの世代管理を理解していない依存関係グラフは、次のジョブステップがこれから読み込もうとしている入力を、実際にどの回のジョブ実行が生成したのかを把握できない。

ツール業界はすでにこれを知っている

これは目新しい指摘ではない——ドキュメントでは捉えきれない依存関係グラフの部分を再構築するために特化したツールのカテゴリが、まさにこの理由で存在している。SMART TS XLのような製品は、COBOLプログラム・JCLジョブ・コピーブック・データ構造をまたいだ依存関係マップを構築する。それは、COBOLだけを単独で静的解析しても、移行コストとスケジュールを左右する複雑性の一部しか明らかにならないからだ。業界分析が繰り返し行き着く、より大きな論点は次のことだ——JCLとCOBOLのマッピングは本質的にリスクマネジメントの実務である。メインフレームシステムへの変更はすべて、実際に変更されたコンポーネントの範囲を超えた影響を及ぼし、その「影響範囲(ブラストレイダス)」が実際に伝播していく先は、たいていJCLだ。

これはどれも、間違えたときの代償が小さい問題ではない。フォーチュン500企業の71%超が、いまなおミッションクリティカルなワークロードをメインフレーム上で稼働させており、メインフレームはIT予算のわずか約6%でありながら、グローバルなIT本番ワークロードの約68%を担っている——依存関係マッピングの誤りが実際の本番リスクにさらすのは、机上演習ではなく、この規模のインフラだ。

Legacy DragonがJCLを「付属ファイル」ではなく第一級言語としてパースする理由

Legacy Dragonは、COBOL・JCL・PL/I・VB6・VB.NET・PowerBuilder・Assembly・SQL/DB2・CICS・REXXという10のソース言語を、単一のASTと依存関係グラフへとパースする。そしてこのリストの中で、JCLはCOBOLを説明するための付属メタデータではなく、COBOLと対等な言語として並んでいる。これは意図的な設計上の配置であり、このグラフの文字コード処理が前処理スクリプトの中ではなくパーサー内部に置かれているのとまったく同じ理由による。JCLを単なる足場として扱ってグラフを構築すれば、ドキュメントベースのあらゆる棚卸しが抱えているのと同じ死角——解決されないままの条件コード分岐、区別できないGDG世代、展開されないシンボリックパラメータ——をそのまま引き継いでしまう。JCLを実際の制御フローを持つ本物の言語としてパースするグラフであれば、ジョブステップ、そのステップが分岐条件とするリターンコード、呼び出されるプログラム、読み書き対象となるGDG世代を、あるCOBOLの段落がどのコピーブックを呼び出すかをすでに追跡している同じ構造の中で、エッジとして表現できる。

これは、JCLとバッチオーケストレーションが独立した新機能ではなく、影響分析の自然な延長である理由でもある。「この変更が何に影響するか」という問いは、2つの一見無関係なプログラム間の実際の結合が、どちらのソースコードにも一度も登場しないジョブステップ内のリターンコードだった場合、COBOLだけを見ていては最初から答えようがなかった。

Legacy Dragonを超えて重要な理由

これは、バッチオーケストレーションがそれをトリガーするCOBOLロジックより難しいという主張でも、JCLが「ついでに扱われる存在」以上の注目に値するという主張でもない。もっと限定的な主張は、依存関係グラフの完全性は、それが実際にパースするよう作られた言語の範囲でしか担保されない、ということだ。そしてメインフレームにおいて、移行を実際に壊す原因のかなりの部分は、プログラミング言語ではなくジョブ制御言語で書かれており、COBOLだけを前提に構築されたほとんどのツールは、そもそもそれを見るようには設計されていない。

---

JCLを、COBOLの周りの足場としてではなく第一級言語としてパースすると依存関係グラフがどう変わるか、興味があればdragon.aitytech.comでLegacy Dragonを確認してほしい。ASTグラフが影響分析を第一の目的として設計されている理由もあわせて読めるほか、[email protected]まで問い合わせることもできる。