ページの先頭行へ戻る
Interstage Job Workload Server V9.2.0 セットアップガイド
第2章 業務構成要素の設計 > 2.3 バッチサーバ環境の設計 > 2.3.2 ジョブの実行環境全体の設計
前次

2.3.2 ジョブの実行環境全体の設計

ジョブの実行環境は、バッチサーバ環境に1～8個作成できます。ジョブの実行環境の全体的な設計には、以下があります。

■ジョブの実行環境の操作モード

イニシエータの起動・停止と連動して、ジョブの実行環境(バッチワークユニットおよびイベントチャネル)を自動で起動・停止するかどうか設計します。
ジョブの実行環境の操作モードには以下があります。


ジョブの実行環境の操作モードは、すべてのジョブの実行環境で共通の設定です。ジョブの実行環境単位での操作モードは設定できません。


■ジョブの実行環境を分ける

ジョブの実行環境の分け方は、以下のとおりです。

ジョブの実行環境を分けるイメージを以下に示します。


ジョブスケジューラ製品であるSystemwalker Operation Managerを例とした場合、以下の図のように、1つのジョブの実行環境を1つの“プロジェクト”に対応づけると、管理が容易になります。


■予備のジョブの実行環境を準備する

予備のジョブの実行環境は以下の場合に準備する必要があります。

修正したアプリケーションを実行するには、アプリケーションを配備する必要があります。しかし、アプリケーションを配備するためには、当該ジョブの実行環境を停止する必要があります。このとき、同じジョブの実行環境で動作しているジョブに影響があります。

このような場合に備えて、予備のジョブの実行環境を準備しておくことで、他のジョブに影響を与えることなく、修正したアプリケーションを呼び出すジョブを投入することができます。
予備のジョブの実行環境のイメージを以下に示します。


ジョブの実行環境を作成できる個数(バッチサーバ環境に1～8個)には、予備のジョブの実行環境の数を含みます。


予備のジョブの実行環境の運用については、“Interstage Job Workload Server 運用ガイド”の“予備のジョブの実行環境の運用”を参照してください。


■ジョブの実行環境単位の設計

ジョブの実行環境単位の設計要素には、以下があります。

ジョブの実行環境単位の設計要素について次に説明します。

2.3.2.1 ジョブの実行環境の設計

ジョブの実行環境を設計する要素には以下があります。

また、以下の観点での設計が必要です。

■ジョブキュー名

ジョブの実行環境の名前として、ジョブキュー名を決定します。
バッチサーバ内において、他のジョブキューと重複しないように設計してください。
決定した名前で、ジョブキュー、およびイニシエータが構築されます。
ジョブキュー名の規約は以下のとおりです。

■ジョブの多重度

ジョブの実行環境内で、同時に実行できる最大ジョブ数を決定します。
ジョブの多重度は、1～64の範囲で指定できます。ただし、システム内のジョブキューのジョブの多重度の合計が、1～64の範囲になる必要があります。
ジョブの実行環境の運用時には、本多重度分プロセスを生成して常駐します。
したがって、運用するバッチ業務で実行するジョブ数や、各ジョブの実行時間などの運用性、バッチサーバのハードウェア性能（搭載CPU、CPU数、メモリ量など）、およびサーバ内の負荷／資源を考慮して設計してください。
ジョブの多重度は、“2.3.2.2 ジョブキューの設計”でのジョブの多重度と合わせて設計してください。

■運用者(オペレータ)の選定

運用者(オペレータ)は、ジョブの投入／操作を行い、バッチ業務を運用します。以下のグループに所属するユーザをバッチ業務の運用単位に選びます。

■マルチジョブコントローラを使用する場合

マルチジョブコントローラを使用する場合は、1つのジョブキューに、カスケード結合数のジョブの多重度が必要となります。カスケード結合数は、カスケード開始節が指定されたジョブステップと、カスケード終了節が指定されたジョブステップを含む、両者間のジョブステップの数のことです。マルチジョブコントローラを使用する場合は、カスケードジョブを実行するジョブキューのジョブの多重度を、カスケード結合数以上としてください。


マルチジョブコントローラおよびカスケード結合数の詳細は、“Interstage Job Workload Server バッチ開発ガイド”の“マルチジョブコントローラ”を参照してください。

■NetCOBOLの小入出力機能でファイルを使用する場合

NetCOBOLの小入出力機能でファイルを使用する場合は、ジョブの実行環境を設計する際にジョブキューとジョブの多重度について考慮が必要です。詳細は、“付録G NetCOBOLの小入出力機能でファイルを使用する場合”を参照してください。

2.3.2.2 ジョブキューの設計

ジョブの実行環境には、ジョブの投入を受け付けるジョブキューが必ず1つ必要です。
ジョブキューには、以下の属性があります。

また、以下の観点での設計が必要です。

■ジョブの多重度

ジョブの実行環境内で、同時に実行できる最大ジョブ数を決定します。
ジョブの多重度は、1～64の範囲で指定できます。ただし、システム内のジョブキューのジョブの多重度の合計が、1～64の範囲になる必要があります。
ジョブの実行環境の運用時には、本多重度分プロセスを生成して常駐します。
したがって、運用するバッチ業務で実行するジョブ数や、各ジョブの実行時間などの運用性、バッチサーバのハードウェア性能（搭載CPU、CPU数、メモリ量など）、およびサーバ内の負荷／資源を考慮して設計してください。

ジョブの多重度を制限することにより、単位時間あたりに処理を完了することができるジョブ数が減少します。このため、投入するジョブ数がジョブの多重度の制限数にあわせて減少しない場合、ジョブスプールおよびジョブキューに設定されている投入可能ジョブ数の上限値を超えて、ジョブの投入が失敗する可能性があります。ジョブの多重度の制限を行う運用を構築する場合は、以下を考慮して設計してください。

  • ジョブの投入数と制限するジョブの多重度にあわせてジョブスプールおよびジョブキューの投入可能ジョブ数を設定する。

また、マルチジョブコントローラを使用する場合は、1つのジョブキューに、カスケード結合数のジョブの多重度が必要となります。カスケード結合数は、カスケード開始節が指定されたジョブステップと、カスケード終了節が指定されたジョブステップを含む、両者間のジョブステップの数のことです。マルチジョブコントローラを使用する場合は、カスケードジョブを実行するジョブキューのジョブの多重度を、カスケード結合数以上としてください。

■投入可能ジョブ数

投入可能ジョブ数とは、対象のジョブキューにキューイングできる、最大のジョブ数です。
投入可能ジョブ数は、0～99,999 の範囲で指定できます。
本設定数を超えてジョブをキューイングすることはできません。
本設定数は、全ジョブキューを管理する、“ジョブスプールの投入可能ジョブ数”と合わせて設計してください。
バッチ実行基盤の既定の設定では、ジョブキューごとの投入可能ジョブ数の制限はしません。

■実行経過時間制限値

実行経過時間制限値とは、対象のジョブの実行環境で、1つのジョブの実行に与えられる時間です。
単位は秒です。
実行経過時間制限値は、1～99,999,999の範囲で指定できます。
この時間を超えて実行したジョブは、キャンセルされ異常終了します。
したがって、業務アプリケーションの無限ループなどの異常によって、1つのプロセスが占有された場合でも、指定時間でジョブを終了することができます。
バッチ実行基盤の既定の設定では、実行経過時間の監視はしません。

■デフォルトジョブキュー

バッチジョブの投入時には、投入先のジョブキューを指定します。
バッチジョブの投入時に、投入先のジョブキューを指定しなかった場合、デフォルトジョブキューとして設定されたジョブキューに、ジョブが自動的に投入されます。
デフォルトジョブキューは、バッチサーバ内で1つだけ設定できます。
したがって、対象のジョブの実行環境の運用性や、バッチシステム全体の利便性を考慮して、デフォルトジョブキューにするか設計してください。

たとえば、デマンドジョブのように運用者が、コマンドを使用して不定期にバッチジョブの投入を行う時があります。
デマンドジョブ専用のジョブキューを設けた場合、そのジョブキューをデフォルトジョブキューに設定することで、デマンドジョブの投入時に誤ったジョブキューに投入することがなくなります。

■マルチジョブコントローラを使用する場合

マルチジョブコントローラを使用する場合は、通常のジョブとは別に、マルチジョブコントローラ専用のジョブキューの作成を推奨します。

カスケードジョブは、ジョブの実行時に動作に必要なカスケード結合数分のプロセス数を確保し、ジョブが終了するまで占有します。確保できなかった場合は実行待ちとなります。このため、他のジョブが動作中のジョブキューでは、カスケード結合数分の空きプロセスが確保できない場合は、実行待ちとなります。
したがって、同時実行される可能性のあるカスケードジョブのカスケード結合数の合計が投入するジョブキューのジョブの多重度より小さくなるように設計してください。

以下に、カスケードジョブと1ジョブキューのジョブの多重度との関係詳細を表で示します。

カスケード結合数(m)と
ジョブの多重度(n)の関係

動作中の
プロセス数(p)

カスケード結合数と
空きプロセス数の関係

投入したカスケードジョブの動作

m ＞ n

－

－

  • 多重度不足のためエラーになります。

m ＜＝ n

0

－

  • 正常に実行されます。

p（＞0）

m ＞ (n－p)

  • 動作中のジョブが終了するまで実行待ちとなります。(*1)

  • 実行待ちの間は後続のジョブも実行待ちとなります。

m ＜＝ (n－p)

  • 正常に実行されます。

*1:後続のジョブに実行優先順位が高いジョブが実行された場合は、後続のジョブが優先されて実行されます。

■C言語アプリケーションとCOBOLアプリケーションが同じジョブキューで動作する場合

以下の場合、C言語のバッチアプリケーションのみが動作する場合においても、COBOLの環境開設が行われます。

したがって、C言語アプリケーションとCOBOLアプリケーションとで動作させるジョブキューを分けることを推奨します。

■NetCOBOLの小入出力機能でファイルを使用する場合

NetCOBOLの小入出力機能でファイルを使用する場合は、ジョブの実行環境を設計する際にジョブキューとジョブの多重度について考慮が必要です。詳細は、“付録G NetCOBOLの小入出力機能でファイルを使用する場合”を参照してください。

2.3.2.3 イニシエータの設計

ジョブの実行環境には、ジョブの実行を制御するイニシエータが必ず1つあります。
イニシエータには、以下の属性があります。

■イニシエータの開始方法

バッチ実行サービスの開始と連動して、イニシエータを自動起動するかどうか設計します。
バッチ実行基盤の既定の設定では、自動起動でイニシエータは起動します。
日常のバッチ業務で使用するジョブの実行環境の場合、自動起動にしておくと便利です。
また、月次業務、年次業務、および予備のジョブの実行環境のように、ある時点でしか使用しないジョブの実行環境の場合、自動ではなく手動で起動するよう設計します。
なお、バッチ実行サービスを停止すると、イニシエータの開始方法の設定に関わらず、バッチ実行サービスの停止と連動してすべてのイニシエータは停止されます。


予備のジョブの実行環境については、“2.3.2 ジョブの実行環境全体の設計”を参照してください。

■イニシエータの開始ユーザ

バッチ実行サービスの開始と連動して、イニシエータを自動起動する場合、開始するユーザ名を指定します。Interstage運用者のユーザ名を指定します。

2.3.2.4 バッチワークユニットの設計

ジョブの実行環境には、バッチジョブ定義で指定されたバッチアプリケーションを実行する環境として、バッチワークユニットが必ず1つあります。
バッチワークユニットの設計には、運用するバッチ業務の、安全性、安定性、耐障害性に関係する要素があります。
以下の設計を行ってください。

■カレントディレクトリ

バッチワークユニットで起動したバッチアプリケーションが動作する作業ディレクトリ(カレントディレクトリ)です。
カレントディレクトリによって、バッチワークユニット配下で動作するバッチアプリケーションは、それぞれ異なった作業ディレクトリで動作することができます。
アプリケーション異常時に出力されるcoreファイルなどもこのディレクトリ上に出力されます。
バッチワークユニット単位に、バッチアプリケーションが動作する作業ディレクトリをどこに配置して運用するか設計してください。

■カレントディレクトリの退避世代数

バッチワークユニットが過去に起動された時のカレントディレクトリを、世代数分残すことができます。
バッチワークユニットが異常終了した場合でも、カレントディレクトリ配下に出力したデータは残るため、バッチ業務復旧を優先してワークユニットを起動したあとでも、カレントディレクトリ配下のデータを採取できます。
バッチ実行基盤の既定の設定では、退避世代数を1で運用します。
バッチ業務の耐障害性を考慮して、退避世代数を設計してください。

■プロセス縮退運用

業務アプリケーションプロセスが異常終了した場合、プロセスが自動的に再起動されます。
このとき、プロセスの起動処理に失敗した場合、プロセス数が1つ少ない状態で運用を継続(縮退運用)する運用を行うか設計します。
バッチ実行基盤の既定の設定では、被害を最小限にするために縮退運用します。
縮退運用を行わない場合、対象のバッチワークユニットが停止するため、そこで実行していたジョブは、すべて異常終了します。
バッチ業務の安全性、安定性、耐障害性を考慮して、縮退運用するかどうか設計してください。

■アプリケーションのプロセスモード


バッチワークユニットで実行する業務アプリケーションをプロセスモードで実行するか決定します。
OSのスレッドライブラリをリンクしていない業務アプリケーションを動作させる場合は、プロセスモードとします。
その逆に、OSのスレッドライブラリをリンクしている業務アプリケーションを動作させる場合には、スレッドモードとします。
混在したアプリケーションを1つのバッチワークユニットで動作させることはできません。
バッチ実行基盤の既定の設定では、アプリケーションの動作モードはスレッドモードです。



バッチワークユニットで実行する業務アプリケーションはスレッドモードのみです。


バッチワークユニットの設定に関する詳細は、“付録D バッチワークユニットの設定”を参照してください。

2.3.2.5 世代ファイルの設計

ファイルの世代管理機能を使用する場合、ファイルの格納先ディレクトリには、保存世代数分のファイルを作成します。その他も考慮し、バッチジョブから使用するファイルの運用に応じて、世代ファイル情報の設計を行ってください。
世代ファイル情報としては以下があります。

■最大世代数

ファイルの世代管理機能では、登録時に指定した最大世代数の世代を管理します。保存する世代数が最大世代数を超えた場合、保存期間内であっても保存対象から外します。
最大世代数の指定可能な範囲は1～10000です。

■最大世代数を超えた場合の処理

世代ファイルで管理する世代数が最大世代数を超えた場合には、世代ファイルを保存対象から外します。世代ファイルを保存対象から外す方式には以下の2つがあります。

■世代の保持期間

ファイルが作成された日から起算して登録時に指定した保持期間を経過した世代については、世代数が最大世代数に達していない場合でも、ファイルの世代管理機能の保存対象から外します。
世代ファイルで管理する各世代のファイルが保存期間を超えた場合には、保存期間を超えた世代だけを保存対象から外します。


保持期間を超えたかどうかの判定は世代ファイル別に以下の契機で行います。

よって、一定期間世代ファイルへのアクセスがなかった場合に、ジョブステップで参照した世代が当該ジョブステップ終了時に保存対象外になる場合があります。以下に例を示します。

■世代ファイルごとの管理対象世代数

世代ファイルごとの管理対象世代数は、保存世代数、世代の保存期間および、保存対象外となった世代の削除をどのような契機で実行するかによって決まります。
世代ファイルごとの管理対象世代数は、ディスク容量見積もり時に必要な情報となります。

世代ファイルの設計内容

世代ファイルごとの管理対象世代数

保存世代数のみ指定

保存世代数で指定した世代数
＋保存対象外世代を削除するまでに作成される世代の数

世代の保存期間のみ指定

保存期間内に作成される世代数
＋保存対象外世代を削除するまでに作成される世代の数

保存世代数と
世代の保存期間の両方を指定

保存世代数で指定した世代数
＋保存対象外世代を削除するまでに作成される世代の数

たとえば、毎日1世代ずつ世代を作成する世代ファイルに対して保存世代数を10世代と指定し、1日1回、保存対象外となった世代の削除する運用の場合には、10（保存世代数）+ 1（保存対象外世代を削除するまでに作成される世代の数）となり、管理対象世代数は11になります。


保存対象外となった世代の削除については、“Interstage Job Workload Server 運用ガイド”の“世代ファイルの運用”を参照してください。

前次
Copyright 2010 FUJITSU LIMITED