IBMメインフレームのバッチ処理をどうする?

SCROLL DOWN

リストへ戻る

IBMメインフレームで実行されているバッチ処理は、オンライン処理の利用が少ない夜間に大量のデータを処理する目的で設計されているものが多くあり、このバッチ処理で使用されるJCL(Job Control Language)は、大量のデータをソートする、プログラムやプロシージャを呼び出す、JCLユーティリティを使用してデータをコピーするなど、多いものでは200を超えるステップを実行しています。

コスト削減などの動機から、バッチ処理をクラウドへ移行したい、もしくは既に社命としてクラウドへの移行が決まっているようなケースでは、移行手法の調査と比較から始めることになりますが、ネット上には移行手法や移行可否についての情報が溢れており、混乱の末にIBMメインフレームの継続を余儀なくされるなど、本来の目的を果たせないケースも少なくありません。
そこで、バッチ処理の移行方法やその選択肢について、順を追って一緒に考えてみたいと思います。

JCLでは何が実行されている?

IBMメインフレームのバッチ処理には欠かせないJCLですが、一般的には次の要素がステップ順に呼び出されて実行されています。

 

  1. JCLユーティリティ
    IBMメインフレームのOSから提供されるプログラム群で、例えばSORTユーティリティを利用してデータを並び替える、IDCAMSユーティリティを使用してVSAMデータセットの定義を行う、などで利用されます。
  2. カタログ式プロシージャ
    共通利用できるJCLを切り出し、複数のJCLから呼び出し可能な形式にしたものです。
  3. OS以外の製品が提供するユーティリティ
    IBMメインフレームOS以外の製品、例えばDb2などが提供するJCLから呼び出し可能なユーティリティです。一見、OSが提供しているものと勘違いしやすいため、提供元をきちんと把握しましょう。
  4. COBOLモジュール
  5. PL/Iモジュール
  6. Easytrieveモジュール
  7. アセンブラモジュール
    No.4,5,6,7は、各プログラミング言語でコーディングしたソースから実行モジュールを生成し、JCLから実行します。

 

Job Control Language=ジョブ制御言語という名前の通り、JCLは各ステップの前後の処理内容を考慮し、1つの流れ(=ジョブ)として処理が完了するまでを制御します。
下記のJCL例では、どのステップをスキップしてもジョブは正常に終了しません。

 

JCL例)

 

JCL例の処理内容)

STEP1:JCLユーティリティを使用して、データセットを削除し、再作成
STEP2:JCLユーティリティとプロシージャを使用して、JCLに書かれたデータをSORT後、一時ファイルに格納
STEP3:COBOLの実行モジュールから一時ファイルのデータを読み込み、作成したデータセットへ出力
STEP4:データセットのデータを確認

 

JCLを移行先環境でも使用するかどうかによって移行時のコストや工数が大きく変動するため、まずはこのJCLをどうするか、から考えてみます。

 

JCLをどうする?

まずはJCLの処理内容を解析して把握することが不可欠ですが、オープン環境にはマッチしない概念であるDASDのバックアップユーティリティやIBMメインフレーム上でコンパイルを行うJCLは排除するなど、移行対象を絞り込み、コストの削減を目指します。
では、前後のステップを考慮して設計されたJCLを移行する際の選択肢にはどのようなものがあるのでしょうか。

 

選択肢と対応策チャート)注意書きの製品は後半でご紹介します。

 

「将来、JCLをメンテナンスすることが困難だ」という理由でJCLの書き換えまたは廃止する場合も、解析するためにはJCLの知識が必要になります。JCLは決まった構文を羅列するだけなので、それほど難しい言語ではありません。また、JCLの修正頻度が少ないようであれば、その箇所を社内でマニュアル化すればJCLを書き換えることなく、そのまま使用できるかもしれません。

 

数万本のJCLを保有するケースと数百本のJCLを保有するケースでは、移行時の負担は大きく異なるため、まずは現行JCLを解析し、選択肢に対するリスクやコストを明確にしたうえで方針を決めることが、後悔のない結果につながります。
続いて、JCLから呼び出される各要素について考えてみます。

 

JCLユーティリティをどうする?

移行先環境はOSが異なるため、当然IBMメインフレームのOSが提供するJCLユーティリティは利用できません。この機能を補うために、代替機能やツールの機能を利用することになります。

 

選択肢と対応策チャート)注意書きの製品は後半でご紹介します。

 

JCLユーティリティ相当の機能を新規作成する場合は、それらを設計し、開発する工数やコストも考慮に入れます。

 

カタログ式プロシージャをどうする?

JCLから呼ばれる共通機能なので、JCLの移行方法と同じ扱いになります。

 

OS以外の製品が提供するユーティリティをどうする?

移行先環境に同じ製品を導入できるか、かつ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段階;システムが稼働する環境を移行=リプラットフォーム

一見、何も変わっていないと思われるかもしれませんが、プラットフォームの移行は大きな1歩です。また、UIが変わらないことによりユーザー教育が不要となる利点や、現行アプリケーションをそのまま利用することにより旧比較テストが実施でき、テスト工数を削減できる利点があります。
ポイントは、移行リスクの排除と移行先環境での安定稼働、かつ、速やかに第2段階へ導くことです。

 

着目点)

  • JCLを含むアプリケーションは必要最低限の修正に留める
  • 移行先環境でシステムが安定稼働するまで、大規模なアプリケーションの追加や修正は実施しない
  • 第2段階に向けて、ユーザーのニーズや運用面での問題を継続的に収集する

 

第2段階;新しい技術を取り入れた改良=モダナイゼーション

第1段階で収集したユーザーのニーズに基づき、入力画面をWebベースの画面に変更する、JCLをシェルなどに書き換えるなどの改修や、アプリケーションをコンテナで稼働させる、更なるコストの削減を目指すなど、自社のゴールを目指したモダナイゼーションを、安定稼働後のこの段階で実施します。
これらを第1段階で実施すると、問題発生時に既存もしくは新しく改良したアプリケーションのどちらに問題があるのか、原因の切り分けが非常に複雑で困難になります。
ポイントは、ユーザーのニーズや新しい技術と文化を取り入れて、競争優位性を強化できる柔軟性、可用性、俊敏性を備えたシステムを実現することです。

 

着目点)

  • ユーザーのニーズに応えるリリースを短期間で継続的に実施する
  • 移行先環境で露見した運用面での問題を継続的に解決する
  • 改良による障害発生時は安定稼働ベースに切り替え、システム停止を回避できる環境を構築する
  • 運用結果から既存機能の必要性を見極める

 

IBMメインフレームのバッチ処理を移行する際には、段階的に取り組むことが可能な、弊社のモダナイゼーション支援製品の導入をご検討いただければ幸いです。

 

COBOL、PL/Iアプリケーションのモダナイゼーションに関するご相談は、下記URLからお気軽にお問合せください。

 

ご相談受付)

https://www.amc.rocketsoftware.co.jp/mfproducts/amc_inquiry/

 

弊社営業部へのお問い合わせ)

https://www.amc.rocketsoftware.co.jp/about/contact/

関連情報

エンタープライズ製品

ロケットソフトウェアのエンタープライズ製品群は、IBMメインフレーム・アプリケーション向けの開発・管理機能を提供します。メインフレームクロス開発やリプラットフォームを可能にし、IBMメインフレーム・アプリケーションのモダナイゼーションを支援します。

COBOL製品

ロケットソフトウェアのCOBOL製品は、COBOL資産を最新環境へモダナイズするための製品群です。MF-COBOLへの移行や Java/.NET/Webサービスとの連携により、低コスト・低リスクで柔軟なシステム構築を可能にします。

【Webセミナー】モダナイゼーション技術セミナー ~リプラットフォームプロジェクトを強力にサポートするエンタープライズ製品~

Enterprise Developer/Enterprise Serverの機能と活用方法について、製品を利用したリプラットフォームの手順やそれに伴う具体的な注意点も解説します。

SNSでシェアする

  • URLをコピーしました