2026.03.19
IBMメインフレームで実行されているバッチ処理は、オンライン処理の利用が少ない夜間に大量のデータを処理する目的で設計されているものが多くあり、このバッチ処理で使用されるJCL(Job Control Language)は、大量のデータをソートする、プログラムやプロシージャを呼び出す、JCLユーティリティを使用してデータをコピーするなど、多いものでは200を超えるステップを実行しています。
コスト削減などの動機から、バッチ処理をクラウドへ移行したい、もしくは既に社命としてクラウドへの移行が決まっているようなケースでは、移行手法の調査と比較から始めることになりますが、ネット上には移行手法や移行可否についての情報が溢れており、混乱の末にIBMメインフレームの継続を余儀なくされるなど、本来の目的を果たせないケースも少なくありません。
そこで、バッチ処理の移行方法やその選択肢について、順を追って一緒に考えてみたいと思います。
IBMメインフレームのバッチ処理には欠かせないJCLですが、一般的には次の要素がステップ順に呼び出されて実行されています。
Job Control Language=ジョブ制御言語という名前の通り、JCLは各ステップの前後の処理内容を考慮し、1つの流れ(=ジョブ)として処理が完了するまでを制御します。
下記のJCL例では、どのステップをスキップしてもジョブは正常に終了しません。

STEP1:JCLユーティリティを使用して、データセットを削除し、再作成
STEP2:JCLユーティリティとプロシージャを使用して、JCLに書かれたデータをSORT後、一時ファイルに格納
STEP3:COBOLの実行モジュールから一時ファイルのデータを読み込み、作成したデータセットへ出力
STEP4:データセットのデータを確認
JCLを移行先環境でも使用するかどうかによって移行時のコストや工数が大きく変動するため、まずはこのJCLをどうするか、から考えてみます。
まずはJCLの処理内容を解析して把握することが不可欠ですが、オープン環境にはマッチしない概念であるDASDのバックアップユーティリティやIBMメインフレーム上でコンパイルを行うJCLは排除するなど、移行対象を絞り込み、コストの削減を目指します。
では、前後のステップを考慮して設計されたJCLを移行する際の選択肢にはどのようなものがあるのでしょうか。

「将来、JCLをメンテナンスすることが困難だ」という理由でJCLの書き換えまたは廃止する場合も、解析するためにはJCLの知識が必要になります。JCLは決まった構文を羅列するだけなので、それほど難しい言語ではありません。また、JCLの修正頻度が少ないようであれば、その箇所を社内でマニュアル化すればJCLを書き換えることなく、そのまま使用できるかもしれません。
数万本のJCLを保有するケースと数百本のJCLを保有するケースでは、移行時の負担は大きく異なるため、まずは現行JCLを解析し、選択肢に対するリスクやコストを明確にしたうえで方針を決めることが、後悔のない結果につながります。
続いて、JCLから呼び出される各要素について考えてみます。
移行先環境はOSが異なるため、当然IBMメインフレームのOSが提供するJCLユーティリティは利用できません。この機能を補うために、代替機能やツールの機能を利用することになります。

JCLユーティリティ相当の機能を新規作成する場合は、それらを設計し、開発する工数やコストも考慮に入れます。
JCLから呼ばれる共通機能なので、JCLの移行方法と同じ扱いになります。
移行先環境に同じ製品を導入できるか、かつIBMメインフレームと同じユーティリティが利用できるかを調査します。

ユーティリティ相当の機能を新規作成する場合は、それらを設計し、開発する工数やコストも考慮に入れます。
複数の開発言語で作成されたソースコードを、移行先環境でどのように開発、運用するかが焦点となる課題です。
メンテナンスには各開発言語の知識が必要となり、すべてをそのまま使用する場合は、移行先環境に必要となる言語の開発や運用が可能なツールを用意する必要があります。
実行モジュールについてはJCLと関係なく考えてみます。

今後の開発や運用に大きな影響を与える決定となるため、開発ツールや自動変換ツールを広く調査し、その品質や実績を確認します。例えばCOBOLは精度の高い計算が得意であるなど、開発言語には特長があり、これを考慮することも重要です。

弊社製品がサポートできる要素を前項の選択肢と対応策チャートにて注意書きとしました。
”注2”としたVisual COBOL/COBOL Serverが属するCOBOL製品は、COBOLアプリケーションをWebサービスとして展開することや、コンテナとして稼働させることもでき、さらに、COBOLソースからJVM、.NET上で稼働できる実行モジュールを生成することもできます。また、SORTやファイル編成の変換など、一部のJCLユーティリティと同等の機能をご提供しています。
「COBOLだから〇〇できない」といった古い固定観念は少しでも払拭できたでしょうか。
次に、“注1”としたEnterprise Developer/Serverが属するエンタープライズ製品は、COBOL製品の全機能に加えて、IBMメインフレームのJCL、CICS、IMS互換機能とPL/I言語の開発と実行をサポートしており、コンテナとして運用することもできます。もちろんIBM JCLユーティリティも実行可能です。
製品機能の詳細については下記のURLをご参照ください。
注1)Enterprise Developer/Server
https://www.amc.rocketsoftware.co.jp/mfproducts/enterprise/developer/
注2)Visual COBOL/COBOL Server
https://www.amc.rocketsoftware.co.jp/mfproducts/COBOL/visualcobol/
移行プロジェクトに予算や期間を潤沢に確保できるケースは少数で、多くのプロジェクトでは限られた予算や期間、かつ、リスクや品質劣化を排除した移行を要求されています。
メインフレームの継続やクラウド環境への移行など、どのような選択をしたとしてもリスクはゼロではありません。自社のシステムにマッチするモダナイズの最終ゴールを定めたうえで、リスクが分散または軽減できる方法を選び、これに基づいた中長期的な移行計画を立てる必要があります。
最後に弊社から、リスクを軽減できる段階的なモダナイズをご提案します。
一見、何も変わっていないと思われるかもしれませんが、プラットフォームの移行は大きな1歩です。また、UIが変わらないことによりユーザー教育が不要となる利点や、現行アプリケーションをそのまま利用することにより旧比較テストが実施でき、テスト工数を削減できる利点があります。
ポイントは、移行リスクの排除と移行先環境での安定稼働、かつ、速やかに第2段階へ導くことです。
第1段階で収集したユーザーのニーズに基づき、入力画面をWebベースの画面に変更する、JCLをシェルなどに書き換えるなどの改修や、アプリケーションをコンテナで稼働させる、更なるコストの削減を目指すなど、自社のゴールを目指したモダナイゼーションを、安定稼働後のこの段階で実施します。
これらを第1段階で実施すると、問題発生時に既存もしくは新しく改良したアプリケーションのどちらに問題があるのか、原因の切り分けが非常に複雑で困難になります。
ポイントは、ユーザーのニーズや新しい技術と文化を取り入れて、競争優位性を強化できる柔軟性、可用性、俊敏性を備えたシステムを実現することです。
IBMメインフレームのバッチ処理を移行する際には、段階的に取り組むことが可能な、弊社のモダナイゼーション支援製品の導入をご検討いただければ幸いです。
COBOL、PL/Iアプリケーションのモダナイゼーションに関するご相談は、下記URLからお気軽にお問合せください。
https://www.amc.rocketsoftware.co.jp/mfproducts/amc_inquiry/
ロケットソフトウェアのエンタープライズ製品群は、IBMメインフレーム・アプリケーション向けの開発・管理機能を提供します。メインフレームクロス開発やリプラットフォームを可能にし、IBMメインフレーム・アプリケーションのモダナイゼーションを支援します。
ロケットソフトウェアのCOBOL製品は、COBOL資産を最新環境へモダナイズするための製品群です。MF-COBOLへの移行や Java/.NET/Webサービスとの連携により、低コスト・低リスクで柔軟なシステム構築を可能にします。
Enterprise Developer/Enterprise Serverの機能と活用方法について、製品を利用したリプラットフォームの手順やそれに伴う具体的な注意点も解説します。