バッチアプリケーションの設計

ジョブの構成設計にもとづいて、バッチアプリケーションを設計します。

バッチアプリケーションの設計時のポイントについて説明します。

・ 生産性を考慮した設計

・ 異常検出時におけるトラブル調査を考慮した設計 また、以下の観点での設計が必要です。

・ マルチジョブコントローラを使用する場合の設計

生産性を考慮した設計

バッチアプリケーションの生産性の向上のために、以下を観点にして設計することを推奨します。

・ 処理の共通部品化

・ 入力パラメタ、環境変数によるデータや処理の切り分け 処理の共通部品化

複数のバッチアプリケーションで共用できる処理が存在する場合は、共通処理をバッチアプリケーションとは別のプログラム（サブ プログラム）にします。これにより、処理を部品化でき、バッチアプリケーション開発の生産性を向上できます。

入力パラメタ、環境変数による処理の切り分け

同じバッチアプリケーションで、部分的に異なった処理を行いたい場合などは、アプリケーションのインタフェースの“入力パラメタ”

および“環境変数”を利用します。入力パラメタや環境変数に処理の切り分けに必要な情報を指定し、バッチアプリケーションでこ の情報を取り込みます。これにより、部分的に異なった処理を同じバッチアプリケーションのソースプログラムに書き込むことができ、

バッチアプリケーションの汎用性が向上します。

異常検出時におけるトラブル調査を考慮した設計

バッチアプリケーションで異常を検出したときのトラブル調査を容易にするため、以下を観点にして設計することを推奨します。

・ 異常検出時における調査情報の取得 異常検出時における調査情報の取得

バッチアプリケーションで検出した各種異常については、異常の原因となったエラー情報をファイルもしくはジョブログに出力するこ とをお勧めします。ジョブログに出力する場合は、バッチアプリケーションの標準出力または標準エラー出力に、異常の原因となっ た情報を出力します。

ジョブログへ出力できる標準出力および標準エラー出力のデータ長には上限があります。詳細は、“2.5.2.3 COBOLアプリケーションの 注意事項”、“2.5.3.3 C言語アプリケーションの注意事項”または“2.5.4.3 コマンド／スクリプトの注意事項”を参照してください。

3.4.1 マルチジョブコントローラを使用する場合の設計

マルチジョブコントローラのカスケードモードを使用する場合のバッチアプリケーションの設計について説明します。

・ 入力ファイル数と出力ファイル数について

・ バッチアプリケーションのロジックについて

入力ファイル数と出力ファイル数について

ジョブの入力ファイルと出力ファイルの構成について、以下のとおり設計する必要があります。

・ カスケードジョブステップは複数のファイルからのデータ入力はできません。

・ カスケードジョブステップは複数のファイルへのデータ出力はできません。

・ 1つのカスケードジョブステップが出力したデータを、複数のカスケードジョブステップおよびジョブステップで入力することはできま

せん。

・ 複数のカスケードジョブステップが出力したデータを、1つのカスケードジョブステップおよびジョブステップで入力することはできま せん。

バッチアプリケーションでのファイルアクセスについてイメージを以下に示します。

バッチアプリケーションのロジックについて

バッチアプリケーションのロジックについて、以下のとおり設計する必要があります。

・ すべてのカスケードジョブステップが同時に動作可能である必要があります。

・ 入力データからレコード単位に処理を完結させるロジックとしてください。ソートなど、入力データをすべて読み込んでから、書き込 むようなバッチアプリケーションのロジックでは、カスケードジョブのメリットを生かせません。

・ データの入出力は連続したジョブステップ間で行ってください。

名前付きパイプに入出力するバッチアプリケーションのイメージを以下に示します。

・ バッチアプリケーションでは、復帰するまでに必ずファイルをオープンしクローズするようにしてください。ファイルのオープンおよび クローズを行わなかった場合はジョブが終わらなくなる場合があります。ジョブが終わらなくなった場合は、“Interstage Job Workload

Server 運用ガイド”の“ジョブが実行終了遅延した場合の対処”を参照して対処してください。

・ カスケードジョブステップ間のデータ入出力は名前付きパイプとなり、異常が発生した場合には名前付きパイプは削除されるため、

アプリケーションのデバックのための情報として使用できません。そのため、アプリケーションのデバック性を考慮し、異常検出時は アプリケーションでデバッグ情報を標準出力に出力しておくことを推奨します。アプリケーションの標準出力はジョブログに出力さ れます。