モダナイズ対象のメインフレームコードベースを AWS Transform for mainframe で確立する
2026-07-02 | Author : 皆川 元
はじめに
こんにちは、Mainframe Modernization Specialist Solutions Architect の皆川元です。
AWS は、メインフレームアプリケーションをモダナイズするための複数のアプローチをサポートしています。いずれのパターン (replatform, refactor, reimagine) を選択しても、モダナイズ対象のワークロードのコードベースは、依存先のサブプログラムや COBOL コピーブック等も含み一貫性ある状態で一式揃っている必要があります。一貫性あるコードベースにすることを、「コードベースの確立」と呼ぶことにします。コードベースが確立していないと、モダナイゼーションプロジェクトの開始の遅延や、実施中の作業量増大など、様々な悪影響に直面することになります。コードベースの提示は、モダナイゼーションプロジェクトを実施するベンダーでは無く、お客様側で担当することになります。
本記事では、メインフレームモダナイゼーションのためのエージェンティック AI サービスである AWS Transform for mainframe を活用して、コードベースを確立する方法を紹介します。なお、実際の操作画面やメッセージは、本記事の記載内容と異なる表示になる場合がありますが、ご了承願います。
(注意) 本投稿に記載の手順は、AWS Transform for mainframe で解析するソースコードを保有していて、リバースエンジニアリングが許可されていることが前提です。
builders.flash メールメンバー登録
builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。
(参考) コードベースの一部が欠落する経緯
長年にわたる運用の中で、担当者の異動・退職やシステム間の依存関係の複雑化により、コードベースに意図せぬ欠落が生じていることは珍しくありません。実際のところ、『ソースコードは全て揃っている』と考えていても、モダナイゼーションプロジェクトで移行ベンダーが受領したコード一式を評価すると欠落が見つかるケースが多くみられます。
コードベースに欠落がある場合の影響
アプリケーションの構成要素の間には依存関係があります。バッチ処理の場合、その構成要素は JCL を起点として、実行するプログラムや、プログラム内に取り込むコード断片に依存しています。JCL の実行対象のカタログ式プロシージャやプログラムが欠落していると、JCL エラーになり実行できません。参照するコピーブックが欠落している COBOL プログラムはコンパイルエラーになり、オブジェクトコード (バイナリー) が生成されません。
モダナイズ対象のコードベースに欠落があると、いずれのパターンを選択しても、右図に示すようにモダナイゼーションを実施できなかったり、間違ったモダナイズ結果になります。一般的に、プロジェクト開始前にコードベースをベンダーに開示してアセスメントを実施し、モダナイゼーションプロジェクトの提案を求めます。このとき、欠落している部分があると、コードの全貌が掴めず、総量を把握できないだけでなく、標準的な移行ソリューションで対応困難な特殊な実装の有無が確認できません。結果的に移行の難易度を正確に把握できず、作業量を精緻に見積もることができません。これらのリスク要因により、作業量は多めに見積もられ、スケジュールが長めに引かれることになります。
サンプルアプリケーション CardDemo の構成
- フォルダー名は、ダウンロード前のメインフレーム上のデータセット名に変更する
- PS以外のファイルの拡張子を全て “.txt“ に変更する
ー PSファイルは、EBCDIC のままバイナリーとしてダウンロードしたテスト用のサンプルデータであり、そのままにしておく
最初のコード分析による欠落コードの特定
ジョブの作成
AWS Transform for mainframe で新しいジョブを作成し、Mainframe Modernization を選びます。ジョブの目的として Code analysis をチャット欄に指定します。確認を求められる場合は、そのまま続行するよう指示します。
サンプルコードをアップロード
コードベースの場所を尋ねられるので、上に添付したサンプルコードベースを Amazon S3 バケットにアップロードし、その ARN を指定します。
コード分析結果の確認
コード分析が終わると、その結果の確認を求められます。ファイルの分類が実際の内容と異なる場合は [Reclassify] ボタンの押下により補正することができますが、今回は詳細な手順は割愛します。 [Missing files] タブに切り替えると、分析済のファイルから依存しているファイルがあることがわかります。ファイルが多数あるため、目的の欠落ファイルをこの画面で特定し難いので、分析結果を Excel ファイルに取り込んで調べることにします。
analyze_code_results.zip をダウンロード
左側のナビゲーションペインに表示されるドキュメントアイコン [Artifacts] をクリックすると、“logs” フォルダーと “results” があることがわかります。“results” フォルダーをクリックし、その中の “analyze_code_results.zip” をダウンロードします。
ファイルを開く
“analyze_code_results.zip” 内にある CSV のうち missing でファイル名が始まるものを Excel で開きます。
指定の列をフィルタリング
欠落しているファイルのうち、その所在を特定して補う必要があるのは以下のものです。
- 実行されるプログラムと CALL により呼ばれるサブプログラム (Type: “Missing Program”)
- プログラムのコード内に埋め込まれるコピーブックやインクルードファイル、マクロ等 (Type: “Missing Copybook”)
上述のものを括り出すべく、B 列 [Type] にフィルターを設定し、“Missing Program” と “Missing Copybook” のみをフィルタリングします。
欠落しているファイルを特定
D 列 [Parents] 欄に参照元のファイルが示されています。必要に応じて参照元のファイルの該当箇所を確認し、欠落しているファイルを特定します。例えば COBOL プログラム “CBSTM03A” は、右図の個所でサブプログラム “CBSTM03B” を呼び出しています。
このように “Missing Program” や “Missing Copybook” として検出された欠落コードがあるコードベースは、メインフレーム上で JCL エラーや、コンパイルエラー、リンケージエディターのエラーを生じる不完全な状態です。そのままモダナイズを進めると問題を生じます。
欠落したファイルを一通り補って、コードベースの更新版を作成します。
欠落コードを補完後の再コード分析
AWS Transform for mainframe で新しい Mainframe Modernization ジョブを作成し、Code analysis を実行します。
コードベースの場所を尋ねられるので、更新したサンプルコードベースを S3 バケットにアップロードし、その ARN を指定します。
missing ファイルを開く
コード分析が終わると、その結果の確認を求められます。上と同じ手順で、分析結果の zip ファイルをダウンロードし、missing の CSV をExcel で開きます。
フィルタリングすると、2 つの COBOL コピーブックが欠落していることがわかります。これらのコピーブックは、最初のコード分析では missing として検出されていなかったファイルです。欠落していたファイルは全て補完したはずなので、奇妙に感じられるかも知れません。
コード分析の結果の確認
最初のコード分析の結果、プログラム CBTRN03C が missing として検出されていました。この時点では、CBTRN03C はコードが無いのでプログラミング言語は不明であり、どのコードに依存しているかも特定できていませんでした。
コードベースの更新版を作成
残りの欠落コードを補完した後のコード分析
AWS Transform for mainframe で新しい Mainframe Modernization ジョブを作成し、Code analysis を実行します。
コードベースの場所を尋ねられるので、直前に更新したサンプルコードベースを S3 バケットにアップロードし、その ARN を指定します。
missing ファイルを開く
コード分析が終わると、その結果の確認を求められます。上と同じ手順で、分析結果の zip ファイルをダウンロードし、missing の CSV をExcel で開きます。
コードベースの確立
依然として欠落しているファイルは多数ありますが、フィルタリングしようとすると、“Missing Program” と “Missing Copybook” が選択肢に無いことから、コードベースを確立できたことがわかります。
ご覧頂いたように、欠落コードを補って解析し直すと、更にそこから派生して新たな欠落コードが検出される、ということが繰り返される場合が少なくありません。結果的に、欠落コードの検出と補完は反復的な作業になります。
“Missing Program” および “Missing Copybook” 以外の欠落しているファイルの取り扱いについて補足致します。
- CALL 文によって呼び出すプログラム名を、直接インラインで指定せず変数名で指定していて、動的に呼び出す実装になっている場合は注意が必要です。呼び出し先のプログラム名を文字列連結等によって合成していると、AWS Transform for mainframe が依存関係を直接特定できない場合があります。“Missing Program” では無く “Missing Dynamic Call Value” として検出された依存先コードは動的に呼び出されますので、呼び元のコードの該当箇所を見て依存先を特定します。
- "Missing Source File" は、複数のコード間の一貫性に関する兆候です。例えば、JCL 内の DD 名が COBOL プログラムの FILE-CONTROL で割り当てられていないとき等に検出されます。
- AWS Transform for mainframe は、例えば、JCL 内の DD 文で参照されている Dataset や PDS の中のデータを読み込んで解析することはありません。そのためコードベースの確立には、“Missing Dataset” および “Missing PDS” 欠落は無視して頂いて結構です。
- モダナイゼーションプロジェクトでは、アセスメント時点で不要であっても、プロジェクト期間内の特定のタイミングで “Missing Dataset” および “Missing PDS” の欠落ファイルも必要になる場合があります。例えば、参照先の Dataset や PDS は、テストやデータ移行に現物のデータが必要になります。具体的には、プロジェクトを実施するベンダーにご相談頂くと良いです。
(参考) 動的呼び出しの例
コードベースを確立する作業の終了条件
今回のサンプルでは、欠落ファイルを徐々に補って行き、最終的に “Missing Program” と “Missing Copybook” が無い状態にまで持って行くことができました。しかし、現実のアプリケーションではこのようにならないケースがあります。
例えば、missing の呼び元がモダナイズ対象外の場合は、“Missing Program” および “Missing Copybook” を補う必要が無いと考えられます。モダナイズ対象外である呼び元がノイズになるようであれば、コードベースから除外しても良いかも知れませんが、具体的には、プロジェクトを実施するベンダーにご相談頂くと良いです。
ロードモジュール (バイナリ) のみ存在し、ソースコードが散逸してしまったプログラムは、それ以上探しようが無ければ探索を中断し、アセスメントを担当するベンダーに伝えて頂くと良いです。サードパーティ製のユーティリティ等、そもそもソースコードが無いものも同様です。
欠落コードの探索と補完は反復的な作業になりがちですが、どのような状態で目途を付けてアセスメントに進むか、適宜判断することが重要です。
考慮事項
本記事で紹介した方法でコードベースを確立する際の考慮点を以下に示します。
- 多くの組織で、ソースコードは各システム単位に管理されていますが、欠落コードの特定と提供には、ソースコードを管理している社内の関係者や、アプリケーションの構造を理解している有識者の協力が不可欠です。メインフレーム環境からコードを持ち出す作業は、欠落コードの検出と補完を繰り返すという特性により、一度で済まない可能性があります。プログラム管理台帳に記載されていない欠落コードは、実行時に JOBLIB や STEPLIB で参照している他システムのライブラリーに収録されているかも知れません。組織的に取り組むことができるよう、社内の協力体制を確立した上でコードベースの確立作業を始めると良いでしょう。
- コードベース以外にも、モダナイゼーションプロジェクトのアセスメント時に必要になる作成物があります。以下に一例を示しますが、具体的には、プロジェクトを実施するベンダーにご相談頂くと良いです。
ー ユーティリティの実行時に指定する制御ステートメント: SYSIN DD 等で渡すインラインステートメントをコントロールファイルとして外出しして管理している場合がある。
ー ジョブスケジューラーのジョブネットワーク定義
ー 運用手順書に従って作業員が手動で実行している定例作業
まとめ
冒頭で述べたように、どのようなアプローチでメインフレームモダナイゼーションを進める場合も、一貫性あるコードベースの確立が必要です。本記事では、AWS Transform for mainframe を活用して欠落コードを効率的に検出し、反復的なプロセスでコードベースを確立する手順を示しました。長年の悲願であるモダナイゼーションプロジェクトが開始したのに、コードベースが不完全だと、様々な弊害があります。
- プロジェクトチームがアイドル状態で待機せざるを得なくなった
- 欠落コードを社内で探索/発掘するのに数週間掛かった
- プロジェクト開始後に見つかった欠落コードを移行するために追加作業が発生した。そのためプロジェクト予算を超過してしまい、プロジェクト期間をオーバーランしてしまった。
このような苦労話を耳にすることがよくあります。もし予算化できた暁にモダナイゼーションプロジェクトをジャンプスタートしたいのであれば、実験的なプログラム変換等よりも、コードベースの確立は本格始動に向けて先行実施できる最も有効で確実な準備の一つです。
筆者プロフィール
皆川 元
アマゾン ウェブ サービス ジャパン合同会社
メインフレームモダナイゼーション スペシャリスト ソリューションアーキテクト
新卒で入社した会社で七年半アセンブラープログラミングしていました。AWS サービスを活用したメインフレームモダナイゼーションを検討中のお客様や AWS パートナー様をご支援しています。好きなサービスは AWS Nitro System です。
