JP6191301B2 - 情報処理装置、ジョブスケジューリング方法およびジョブスケジューリングプログラム - Google Patents

Description

本技術は、情報処理装置、ジョブスケジューリング方法およびジョブスケジューリングプログラムに関する。

サーバ、ストレージおよびネットワークなどで稼働するＯＳ（Operating System）／ミドルウェア／アプリケーションによって構成されるシステムでは、ジョブを自動化して運用するためのジョブスケジューリングが行われている。

ジョブを実行して所定の業務を行う場合、通常は、いつまでにジョブの実行を終了させるかという期限が設定される。例えば、銀行などのシステムでは、オンライン業務の開始時刻までに、夜間に実行したジョブを終了させておかなければならない。ジョブの自動化には、このように実行終了時刻を組み入れたジョブスケジューリングが行われる。

ジョブスケジューリングの従来技術としては、例えば、基準多重度と予定多重度を用いて、ジョブシナリオが実行される処理予定時間を算出する技術が提案されている。
また、特定ジョブの開始時刻に影響を及ぼすクリティカルパスを判別し、特定ジョブの終了時刻が目標終了時刻より遅いときに、クリティカルパス上のジョブの優先度を高める技術が提案されている。

さらに、バッチジョブとその実行スケジュールを取得し、バッチジョブの負荷レベルが所定負荷レベルのバッチジョブのみを実行し、バッチジョブの実行が終了するまでは次のバッチジョブを実行しない技術が提案されている。

さらにまた、始点ジョブと終点ジョブとの間で順方向検索を行ってクリティカルパスを求め、また終点ジョブから特定ジョブを逆方向検索してクリティカルパスを求めて、順方向と逆方向でクリティカルパスが異なる場合、実行所要時間が長い方を正規のクリティカルパスとして実行所要時間を算出する技術が提案されている。

特開２０１０−２３１６９４号公報 特開２００４−２９５７３１号公報 特開２０１１−０４３９６８号公報 特開２００９−０４３１８８号公報

上記のように、通常、ジョブの運用では納期があるため、自動化するジョブの実行終了時刻を予測したスケジューリングが行われるが、ジョブの実行時間は、日時等によって変動する。例えば、ジョブの実行に要する時間が一定周期で長くなる期間が発生する場合がある。

このため、単に平均時間などにもとづき、ジョブの実行が長期化する期間において、ジョブ実行を固定的に予測して、ジョブスケジューリングを行うと、ジョブ実行に遅延が生じて、納期内に業務を終わらすことができないといった問題が生じる。

１つの側面では、本発明は、ジョブ実行の遅延を抑制する情報処理装置、ジョブスケジューリング方法およびジョブスケジューリングプログラムを提供することを目的とする。

１つの案では、情報処理装置が提供される。情報処理装置は、ジョブの実行に要する第１の実行時間と、前記第１の実行時間よりも時間が長い第２の実行時間と、を保持する保持手段と、ジョブの実行開始時刻が、特定の時間範囲に含まれるか否かを判断して、前記第１の実行時間または前記第２の実行時間を選択し、選択した実行時間にもとづきジョブのスケジューリングを行うジョブスケジューリング手段とを有する。

１態様によれば、ジョブ実行の遅延を抑制することが可能になる。

情報処理装置の構成例を示す図である。 ジョブ管理サーバの構成例を示す図である。 ジョブスケジューラの構成例を示す図である。 ジョブフロー定義テーブルの構成例を示す図である。 ジョブ定義テーブルの構成例を示す図である。 実行実績時間テーブルの構成例を示す図である。 クリティカルパスのジョブフローとクリティカルパスでないジョブフローとを示す図である。 優先度設定テーブルの構成例を示す図である。 ジョブ実行時の優先度付けを説明するための図である。 ジョブ実行時の優先度付けを説明するための図である。 クリティカルパスのジョブフローとクリティカルパスでないジョブフローとを示す図である。 ジョブスケジューリングを示す図である。 ジョブスケジューリングを示す図である。 ジョブスケジューリングを示す図である。 評価後の新しいクリティカルパスを示す図である。 ジョブスケジューリングを示す図である。 ジョブスケジューリングを示す図である。 ジョブスケジューリングを示す図である。 評価後の新しいクリティカルパスを示す図である。 ジョブスケジューリングを示す図である。 ピーク実行日登録部の動作を示すフローチャートである。 クリティカルパス設定部の動作を示すフローチャートである。 優先度設定部の動作を示すフローチャートである。 実行実績時間算出部の動作を示すフローチャートである。 クリティカルパス評価部の動作を示すフローチャートである。 本実施の形態に用いるコンピュータのハードウェアの一構成例を示す図である。

以下、本発明の実施の形態を図面を参照して説明する。図１は情報処理装置の構成例を示す図である。情報処理装置１は、保持手段１ａとジョブスケジューリング手段１ｂを備える。

保持手段１ａは、ジョブの実行に要する第１の実行時間と、第１の実行時間よりも時間が長い第２の実行時間とを保持する。ジョブスケジューリング手段１ｂは、ジョブの実行開始時刻が、特定の時間範囲に含まれるか否かを判断して、第１の実行時間または第２の実行時間を選択し、選択した実行時間にもとづきジョブのスケジューリングを行う。

ここで、時間範囲Ｈ０は、期間Ｈ１（第１の期間）と期間Ｈ２（第２の期間）を含む。期間Ｈ２は、期間Ｈ１よりも単一ジョブの実行に要する時間が長期化する期間であって、一定周期で発生する期間である。例えば、期間Ｈ１は、業務が平均的に行われる通常日に該当し、期間Ｈ２は、通常日よりも業務が繁忙となるピーク日に該当する。

ジョブスケジューリング手段１ｂは、ジョブの実行開始時刻が、期間Ｈ１に含まれる場合は、ジョブの実行時間として第１の実行時間を選択する。すなわち、期間Ｈ１で実行されるジョブａ１に対しては、第１の実行時間（第２の実行時間よりも時間が短い）を選択する。

また、ジョブスケジューリング手段１ｂは、ジョブの実行開始時刻が、期間Ｈ２に含まれる場合は、ジョブの実行時間として第２の実行時間を選択する。すなわち、期間Ｈ２で実行されるジョブａ２は、ジョブａ１よりも実行所要時間が長いので、第１の実行時間よりも時間が長い第２の実行時間を選択する。

従来では、実行時間が変動するジョブに対して、当初予測した固定的な実行時間をそのまま割り当ててジョブスケジューリングを行っていたため、ジョブ実行に遅延が生じる場合がある。

これに対し、ジョブスケジューリング手段１ｂでは、ジョブの実行時間が長期化するような期間で、ジョブの実行が開始されるか否かを判断する。そして、ジョブの実行所要時間の変動を認識し、時間の長さが互いに異なる第１、第２の実行時間を適応的に選択してジョブのスケジューリングを行う。これにより、ジョブ実行時間の変動に応じた柔軟なジョブスケジューリングを行うことができ、ジョブ実行の遅延を抑制することが可能になる。

次に本技術の構成・動作を説明する前に解決すべき課題について説明する。ジョブの自動運用では、日次バッチ（例：毎日１７：００）や週次バッチ（例：毎週金曜日）など、周期的にジョブを実行するようなスケジューリングが組まれることが多い。

この場合、同じ時間帯や曜日であっても、ジョブを実行する日付によっては、ジョブの実行処理に要するデータ量が変化して、ジョブの実行時間も変化することになる。
例えば、１カ月分の集計日が２０日締めなら毎月の１９日が、ジョブ処理が繁忙する日となる、といったようにジョブの実行に要する時間が長くなる期間が一定周期で発生したりする場合がある。

このような、実行時間が変動するジョブに対して、当初予測した固定的な実行時間でジョブスケジューリングを行うと、実際の実行時間との間にずれが生じて、ジョブ実行に遅延が生じてしまう場合がある。

また、最も長時間でジョブを実行する実行日に合わせてスケジューリングを組むと、短時間でジョブが実行されるような実行日の場合には、ジョブを実行するサーバリソースに余裕が生まれるので、サーバリソースを効率よく使用することができない。

一方、多くのジョブを実行する場合、ジョブフローの全体実行時間が最も長くなるルートであるクリティカルパス（critical path）を設定し、クリティカルパス上のジョブを、クリティカルパス上にないジョブよりも優先的に実行するようジョブスケジューリングが行われる。

しかし、ジョブの実行時間は、上述のように、ジョブの実行日などにより変動する。このため、ジョブスケジューリング立案当初の実行予測時間でクリティカルパスを決定し、該クリティカルパス上のジョブの優先度にもとづくジョブの実行を行うと、実行時間に変動が生じた場合、ジョブフロー全体の実行時間に遅延が生じてしまう。本技術は、このような点に鑑みてなされたものであり、上記の課題を解決するものである。

次に情報処理装置１の機能を含むジョブ管理サーバの構成および動作について以降詳しく説明する。
図２はジョブ管理サーバの構成例を示す図である。ジョブ管理サーバ２は、ジョブスケジューラ１０、ジョブ実行制御部２０、情報管理部３０およびユーザインタフェース部４０を備える。なお、情報管理部３０は、図１の保持手段１ａの機能を含み、ジョブスケジューラ１０は、図１のジョブスケジューリング手段１ｂの機能を含む。

ジョブスケジューラ１０は、ジョブのスケジューリングを行う。ジョブ実行制御部２０は、ジョブスケジューリングにもとづきジョブを実行する。情報管理部３０は、ジョブの実行に関する各種情報の登録管理を行う。ユーザインタフェース部４０は、外部端末と接続してユーザインタフェース処理を行い、外部端末と通信を行う。

図３はジョブスケジューラの構成例を示す図である。ジョブスケジューラ１０は、ジョブ登録部１１、実行日登録部１２、ピーク実行日登録部１３、クリティカルパス設定部１４、実行条件抽出部１５、優先度設定部１６、実行依頼部１７、実行実績時間算出部１８およびクリティカルパス評価部１９を備える。

ジョブ登録部１１は、実行対象のジョブの登録を行う。実行日登録部１２は、ジョブを実行させる日付（実行日）を登録する。ピーク実行日登録部１３は、業務がピークとなるときのジョブの実行日であるピーク実行日を登録する。なお、実行日とピーク実行日は、ユーザインタフェース部４０を介してユーザから任意に設定可能である。

クリティカルパス設定部１４は、終了予定時刻があるジョブフローのクリティカルパスを設定する。実行条件抽出部１５は、ジョブの実行条件を抽出する。優先度設定部１６は、ジョブの実行時または終了時に、システム多重度とジョブの実行数とを比較し、実行するジョブの優先度を決定する。また、優先度設定部１６は、クリティカルパス上にあるジョブの優先度を、クリティカルパス上にないジョブの優先度よりも高く設定する。

実行依頼部１７は、優先度の高い順にジョブの実行をジョブ実行制御部２０へ依頼する。なお、実行依頼されたジョブは、ジョブ実行制御部２０によって実行され、ジョブの実行が終了すると、ジョブ実行制御部２０から実行依頼部１７へ終了応答が送信される。

実行実績時間算出部１８は、ジョブの実行または終了時に、ジョブ実行の開始時刻と終了時刻の差分を算出して実行実績時間を算出する。クリティカルパス評価部１９は、ジョブの実行または終了時に、ジョブの実行予測時間の比較結果により、現在設定されているクリティカルパスが最遅延の経路であるか否かの評価を行う。そして、現在設定されているクリティカルパスが最遅延経路でなければ、新たなクリティカルパスの設定指示をクリティカルパス設定部１４に送信する。

次に情報管理部３０が備えるジョブフロー定義テーブルＴ１とジョブ定義テーブルＴ２について説明する。
図４はジョブフロー定義テーブルの構成例を示す図である。ジョブフロー定義テーブルＴ１は、実行順序を指定した複数のジョブの集まりであるジョブフロー（ジョブネット）に関する定義情報を登録する。

ジョブフロー定義テーブルＴ１は、テーブルメンバとして、version、dbsize、tasknetname、tasknet comment、tasknet start time、tasknet end time、Start mode、Exec hour、Exec min、Start hour、Start min、Exec ymdおよびPeak exec ymdを有する。

各メンバの意味は、versionはバージョン情報、dbsizeはテーブルサイズ、tasknet nameはジョブ名、tasknet commentはコメント、tasknet start timeはジョブの実行開始時刻、tasknet end timeはジョブの終了時刻である。

また、Start modeは実行条件、Exec hourは単一ジョブが実行するときの実行予測時間（時）、Exec minは単一ジョブが実行するときの実行予測時間（分）、Start hourは複数回ジョブが実行するときの実行予測時間（時）である。

さらに、Start minは複数回ジョブが実行するときの実行予測時間（分）、Exec ymdはジョブの実行日（通常実行日）およびPeak exec ymdはジョブのピーク実行日である。
図５はジョブ定義テーブルの構成例を示す図である。ジョブ定義テーブルＴ２は、テーブルメンバとして、task command、task pathname、job comment、microJES id、task number、previous task num、Sys multi num、Prev start time、Prev end time、Prev exec time、exec time、Peak exec time、criticalpath flg、priority jobおよびextention timeを有する。

各メンバの意味は、task commandはジョブのコマンド名、task pathnameはジョブのディレクトリ、job commentはジョブのコメント、microJES idはジョブ名、task numberはジョブ番号、previous task numは先行ジョブ番号である。

また、Sys multi numはシステム多重度、Prev start timeは前回の開始時刻、Prevend timeは前回の終了時刻、Prev exec timeは前回の実行実績時間、exec timeは実行実績（予測）時間である。

さらに、Peak exec timeはピーク実行日の実行予測時間、criticalpath flgはクリティカルパス上の有無、priority jobはジョブの優先度およびextention timeは実行までの猶予時間である。

なお、上記の属性において、「システム多重度」は、ユーザが設定可能である。「前回の開始時刻」は、前回にジョブを実行したときの開始時刻を表す。「前回の終了時刻」は、前回にジョブを実行したときの終了時刻を表す。

「前回の実行実績時間」は、「前回の終了時刻」から「前回の開始時刻」を引いた差分である。「実行実績（予測）の時間」は、前回の実行実績時間またはピーク時の実行実績時間からの次の実行時の予測時間を表す。

「ピーク実行日の実行予測時間」は、ピーク実行日にジョブ実行に要する実行予測時間を表す。「クリティカルパス上の有無」は、ＯＮは、クリティカルパス上のジョブであり、ＯＦＦは、クリティカルパス以外のジョブである。

「ジョブの実行優先度」は、一例としては、０〜６４の範囲で設定され、標準値は３１とする。クリティカルパス上のジョブは優先度が上昇する（遅延が拡大するような場合は、更に優先度を上昇させる）。

また、クリティカルパス以外のジョブでは、優先度は基本的に標準値とする。ただし、実行予定時間帯にシステムのリソース不足（多重度不足など）が予測される場合は、優先度は減少する。猶予時間に余裕がある範囲では優先度はより低下するが、猶予時間が無くなるにつれ優先度は上昇する。

「実行までの猶予時間」はクリティカルパスの終了時刻、または終了予定時刻（納期）までの残り時間から、自身の実行予測時間を減算した値が設定される。猶予時間の範囲では、ジョブの実行時間を遅延させることが可能となる。

次にジョブの実行実績時間と実行予測時間との登録処理について説明する。図６は実行実績時間テーブルの構成例を示す図である。情報管理部３０は、実行実績時間テーブルＴ３を備える。

実行実績時間テーブルＴ３は、ジョブ名、前回の開始時刻、前回の終了時刻、前回の実行実績時間、ピーク実行日の実行予測時間およびピーク実行日情報の項目を有する。
例えば、ジョブＤにおいて、前回の実行開始時刻が00:10であり、終了時刻が00:15であるので、前回の実行実績時間は00:05（＝00:15−00:10）となる。また、ピーク実行日情報が２０１３年の１月４日と１月１１日であり、該ピーク実行日の実行予測時間は00:10となっている。

なお、ピーク実行日の実行予測時間は、ピーク日でない通常実行日の実行実績時間よりも長くなるので、ジョブＤの場合、ピーク実行日の実行予測時間は、通常実行日の実行実績時間よりも５分（＝00:10−00:05）長くなっている。

ここで、ジョブスケジューラ１０内の実行実績時間算出部１８は、ジョブの開始時刻と終了時刻との差分を算出し、当該ジョブの実行日がピーク実行日と一致していない場合は（通常実行日の場合は）、その算出値をジョブ定義テーブルＴ２の「前回の実行実績時間」に対して更新する。

また、実行実績時間算出部１８は、当該ジョブの実行日がピーク実行日と一致している場合は、その算出値と、ジョブ定義テーブルＴ２の「ピーク実行日の実行予測時間」とを比較する。

そして、実行実績時間算出部１８は、すでに設定済みの「ピーク実行日の実行予測時間」の値よりも算出値の方が大きい場合は、「ピーク実行日の実行予測時間」を該算出値よりも大きな値（例えば、ユーザによって任意に設定される値）に更新する。また、すでに設定済みの「ピーク実行日の実行予測時間」の値の方が該算出値よりも大きい場合には、「ピーク実行日の実行予測時間」の値を維持する。

上記のように、ジョブ管理サーバ２では、定期的にスケジュールしている通常実行日のジョブの過去の実行時間と、業務ピーク時の実行日の情報とをそれぞれ、過去の実行実績時間、または業務ピーク時の実行予測時間として登録する。

このように、業務毎に期末、週末など、データが増大しうるタイミングとして、ジョブの定義に周期性に関する情報を付与することで、単純な前回の実績時間と比較することにより精度の高い実行時間が予測することが可能になる。また、事前にすべてのジョブの実行時間がおおよそ見積もれるため精度の高いクリティカルパスの設定が可能である。

なお、上記では、ピーク実行日の実行予測時間は、ユーザから入力するものとしたが、ジョブ実行の一定期間の実績を統計情報として取得しておき、ピーク時の周期性をプログラムにより求めて、プログラムによりピーク時の実行予測時間を求めることも可能である。

さらに、過去に実行したことが無いジョブ（例：ジョブ定義直後、ジョブの定義変更直後など）の実行予測時間に対しては、システム全体で未指定時の値（例えば、未指定時は１０分とするなど）をあらかじめ設定しておいて、その値を採用するようにする。

次にクリティカルパスについて説明する。ジョブスケジューリングでは、ジョブフローの全体実行時間（開始ジョブから最終ジョブまでに要する実行時間）が算出される。このとき、複数のジョブフローの中で、全体実行時間が最大になるルートがクリティカルパスとなる。

クリティカルパス上にないジョブは、実行に遅れが出ても余裕範囲内であれば業務全体のスケジュールには影響しない。これに対し、クリティカルパス上のジョブの実行が遅延すると、業務全体の納期を遅らせてしまうことになる。逆に、クリティカルパスが短縮できると業務期間も短縮できることになる。

図７はクリティカルパスのジョブフローとクリティカルパスでないジョブフローとを示す図である。ジョブフローｆ１は、ジョブＡ、Ｂ、Ｃ、Ｄを含み、ジョブＡは開始ジョブ、ジョブＤは最終ジョブである。なお、途中のジョブＢとジョブＣは、並列に（２多重で）実行されるジョブである。

また、ジョブＡ、Ｂ、Ｃ、Ｄそれぞれの実行予測時間を、１０分、２０分、２０分、１０分とすると、ジョブＢ、Ｃは並列実行されるから、ジョブフローｆ１の全体実行時間は４０分（＝１０＋２０＋１０）となる。

一方、ジョブフローｆ２は、ジョブＥ、Ｆを含み、ジョブＥは開始ジョブ、ジョブＦは最終ジョブである。また、ジョブＥ、Ｆそれぞれの実行予測時間を、５分、１０分とすると、ジョブフローｆ２の全体実行時間は１５分（＝５＋１０）となる。

ここで、ジョブフローｆ１の方がジョブフローｆ２よりも全体実行時間が長いと予測されるので、ジョブフローｆ１、ｆ２に対しては、ジョブフローｆ１がクリティカルパスとなる（図中の積算時間については後述する）。

また、ジョブに優先度を設定する場合、クリティカルパス上のジョブの優先度を、クリティカルパス以外のジョブよりも高く設定する。このような優先度設定をしておくことで、ある時間で複数のジョブが実行対象となったときに、リソースに制約があるような場合でも、クリティカルパス上のジョブを優先して実行することができる。

なお、上記では、複数のジョブフローの中で、全体実行時間が最も長いジョブフローをクリティカルパスとしたが、ジョブに終了予定時刻（納期）が設定されている場合は、終了予定時刻が最も早い（納期が最も早い）ジョブフローをクリティカルパスとして同等に扱い、優先度を設定することになる。

次にクリティカルパスの設定からクリティカルパス上のジョブへの優先度設定までの処理の流れについて説明する。
（１）クリティカルパス設定部１４は、ジョブスケジューリング時（例えば、日変わりで１日分のジョブの実行予定をスケジューリングする場合など）、ジョブフロー内のジョブの実行予測時間をジョブ定義テーブルＴ２から取得する。

そして、クリティカルパス設定部１４は、ジョブに終了予定時刻（納期）が設定されていなければ、ジョブフローの最終ジョブまで、各ジョブの実行予測時間を積算して、ジョブフローの全体実行時間を算出する。

（２）クリティカルパス設定部１４は、実行予測時間の積算処理にあたり、ジョブの実行日がピーク実行日に該当する場合は、ジョブ定義テーブルＴ２の「ピーク時の実行予測時間」を使用する。また、ピーク実行日以外の場合は、ジョブ定義テーブルＴ２の「実行実績時間」を使用する。

（３）クリティカルパス設定部１４は、全体実行時間を求める際の実行予測時間の積算処理では、ジョブフローの最終ジョブから逆算して求める。したがって、まず、最終ジョブがどれかを検索する。

最終ジョブの検索処理では、自分自身が先行ジョブとして設定されていないジョブを検索することで最終ジョブを見つけることができる。すなわち、自分自身が他ジョブよりも実行処理が先行される先行ジョブの場合は、先行ジョブ番号が付されており、最終ジョブには先行ジョブ番号が付されていないので、クリティカルパス設定部１４は、先行ジョブ番号を有していないジョブを最終ジョブと検出する。

（４）クリティカルパス設定部１４は、積算処理において、最終ジョブから開始ジョブの方向に実行予測時間を加算していく。図７の例であれば、ジョブフローｆ１に対して、ジョブＤは、最終ジョブであり、自身の実行予測時間は１０分なので、ジョブＤにおける積算時間は１０分となる。

また、ジョブＤに先行するジョブＢ、Ｃでは、ジョブＢ、Ｃの内、最大の積算時間を加算する。この例では、ジョブＢ、Ｃの実行予測時間は共に２０分であり、後段のジョブＤの積算時間が１０分であるから、ジョブＢ、Ｃにおける積算時間は３０分（＝２０＋１０）となる。

さらに、ジョブＢ、Ｃに先行されるジョブＡでは、ジョブＡの実行予測時間は１０分であり、後段のジョブＢ、Ｃまでの積算時間が３０分なので、ジョブＡにおける積算時間は４０分（＝１０＋３０）となる。

同様に、ジョブフローｆ２に対しては、ジョブＦは、最終ジョブであり、自身の実行予測時間は１０分なので、ジョブＦにおける積算時間は１０分となる。また、ジョブＦに先行されるジョブＥは、実行予測時間は５分であり、後段のジョブＦの積算時間が１０分であるから、ジョブＥの積算時間は１５分（＝５＋１０）となる。

（５）クリティカルパス設定部１４は、積算処理の結果、最大の積算時間となるルートをクリティカルパスと設定する。また、優先度設定部１６は、クリティカルパス上のジョブは遅延可能な猶予時間がないものと認識して、クリティカルパス上のジョブの優先度を上昇させる（同一実行条件下での実行選択優先度を高くする）。

ここで、ジョブスケジューリング時に、終了予定時刻（納期）のあるジョブがある場合、クリティカルパス設定部１４は、終了予定時刻のあるジョブ毎にクリティカルパスを求め、優先度設定部１６は、該クリティカルパス上にあるジョブの優先度を上昇させる。

次に優先度にもとづくジョブのディスパッチ処理について説明する。図８は優先度設定テーブルの構成例を示す図である。情報管理部３０は、優先度設定テーブルＴ４を備える。優先度設定テーブルＴ４は、ジョブ名、開始予定時刻、終了予定時刻、積算時間、クリティカルパス上の有無および優先度の項目を有する。

このように登録された優先度にもとづいて、優先度設定部１６は、ジョブをディスパッチする。また、ジョブのディスパッチの開始タイミングとしては、システムリソース（実行多重度）に余裕のある時間帯のジョブ実行時（初回のジョブ実行時）、または先行するジョブの終了時に実施する。さらに、複数のジョブが実行可能な場合、高優先度のジョブが優先的に実行される。

優先度設定部１６は、ジョブ実行時に、ジョブが実行する時間帯に他のジョブが実行するか否かを判断する。同時間帯において、他のジョブが実行する予定であり、かつ実行予定のジョブ数があらかじめ設定するシステムの多重度を超えるような場合には、ジョブ実行の留保を判断する。

図９はジョブ実行時の優先度付けを説明するための図である。縦軸はジョブの種別、横軸は時間である。図７に示したジョブフローｆ１、ｆ２を例にした場合を示しており、システム多重度に制約がないとする。

〔０：００〕ジョブＡ、Ｅの実行が開始される。
〔０：０５〕ジョブＡは実行中である。ジョブＥの実行が終了する。ジョブＦの実行が開始される。

〔０：１０〕ジョブＡの実行が終了する。ジョブＢ、Ｃの実行が開始される。ジョブＦは実行中である。
〔０：１５〕ジョブＢ、Ｃは実行中である。ジョブＦの実行が終了する。

〔０：２０〕ジョブＢ、Ｃは実行中である。
〔０：２５〕ジョブＢ、Ｃは実行中である。
〔０：３０〕ジョブＢ、Ｃの実行が終了する。ジョブＤの実行が開始される。

〔０：３５〕ジョブＤは実行中である。
〔０：４０〕ジョブＤの実行が終了する。
このように、システム多重度を３とすることができれば、上記のスケジューリングは可能である。しかし、システム多重度が２という制約がある場合は、０：１０〜０：１５の時間帯で３多重のジョブ起動となってしまうので、上記のようなスケジューリングを実行することはできない。

図１０はジョブ実行時の優先度付けを説明するための図である。縦軸はジョブの種別、横軸は時間である。図７に示したジョブフローｆ１、ｆ２を例にした場合を示しており、システム多重度を２とする。

〔０：００〕ジョブＡ、Ｅの実行が開始される。
〔０：０５〕ジョブＡは実行中である。ジョブＥの実行が終了する。
〔０：１０〕ジョブＡの実行が終了する。ジョブＢ、Ｃの実行が開始される。

〔０：１５〕ジョブＢ、Ｃは実行中である。
〔０：２０〕ジョブＢ、Ｃは実行中である。
〔０：２５〕ジョブＢ、Ｃは実行中である。

〔０：３０〕ジョブＢ、Ｃの実行が終了する。ジョブＤ、Ｆの実行が開始される。
〔０：３５〕ジョブＤ、Ｆは実行中である。
〔０：４０〕ジョブＤ、Ｆの実行が終了する。

ここで、ジョブＥが終了した時点（０：０５）では、０：０５で他に実行中のジョブはジョブＡのみなので（現在利用中の多重度は１）、図９に示したように後続のジョブＦの実行が考えられる。ただし、ジョブＦの実行予測時間帯は０：０５〜０：１５であるので、この時間帯には、ジョブＢ、Ｃも動作する可能性があり、その場合は最大多重度が３になってしまう。

ここで、０：０５から０：１０まで、ジョブＡの実行経過時間は５分であり、図７に示すように、ジョブＡの積算実行時間は４０分である。よって、優先度設定部１６は、まず、実行経過時間の５分を引き、ジョブＡの残りの予測積算実行時間３５分を算出する。

一方、ジョブＦの予測積算実行時間は１０分である。優先度設定部１６は、クリティカルパス上のジョブＡの残り予測積算実行時間との比較により、猶予時間は３５分であるから、ジョブＦの実行時間１０分を減じた値、すなわち２５分間は猶予があると判断する。

そして、優先度設定部１６は、ジョブＦの猶予時間の範囲でシステム多重度の上限を超過しない時間帯を求める。この場合、２５分後（０：３０）であれば、自身を除いたシステム多重度が１多重（１多重度の余裕がある）と判断して、ジョブＦの実行開始を２５分後まで猶予可能と認識する。

これにより、システムの利用可能なリソース内で、優先度を上昇させるだけではなく、積極的に優先度の低いジョブを遅延させてジョブスケジューリングを行うことにより、ジョブ実行の遅延を防止することが可能になる。

ここで例えば、ジョブスケジューラ１０は、１日の運用の開始時においては、目標終了時刻が設定されたジョブのクリティカルパスを求め、クリティカルパス上にあるジョブは優先度を上げてジョブの開始時刻の変更は実施せずに起動する。

一方で、ジョブスケジューラ１０は、クリティカルパス上に無いジョブについては、猶予時間と実行予測時間の範囲でリソースが不足すると思われる時間帯に、積極的に優先度を下げて、ジョブの実行時間を遅らせる。これにより、優先度の高いジョブへの影響を無くし、システム全体のジョブ実行の遅延を防止することができる。

次にクリティカルパスの評価処理について説明する。クリティカルパスの評価は、以下の条件＃１、＃２のどちらか一方が満たされる場合に実施される。
（条件＃１）：ジョブの実行開始時において、クリティカルパス上にあるジョブであって、かつ当該ジョブの実際の実行時間が実行予測時間よりも短くなる場合（実行予測時間＞実際の実行時間）。

（条件＃２）：ジョブの実行開始時において、クリティカルパス上にないジョブであって、かつ当該ジョブの実際の実行時間が実行予測時間よりも長くなる場合（実行予測時間＜実際の実行時間）。

条件＃１は、クリティカルパス上のジョブについて、実際の実行時間が実行予測時間よりも短かったことにより、クリティカルパス上になかったジョブが、新たなクリティカルパス上のジョブとなる可能性を示している。

また、条件＃２は、クリティカルパス上になかったジョブについて、実際の実行時間が実行予測時間よりも長くなったことにより、クリティカルパス上になかったジョブが、新たなクリティカルパス上のジョブとなる可能性を示している。

次に具体的な例を挙げてクリティカルパスの評価処理について説明する。図１１はクリティカルパスのジョブフローとクリティカルパスでないジョブフローとを示す図である。
ジョブフローｆ１１は、ジョブＡ、Ｂ、Ｃ、Ｄ、Ｅを含み、ジョブＡは開始ジョブ、ジョブＥは最終ジョブであり、実行順序を図の矢印で示している。なお、フロー途中のジョブＣとジョブＤは、２多重で実行されるジョブとしている。

実行予測時間は、ジョブＡ、Ｂ、Ｃ、Ｅそれぞれは１０分であり、ジョブＤは５分である。したがって、ジョブフローｆ１１の全体実行予測時間は４０分（＝１０＋１０＋１０＋１０）となる。

一方、ジョブフローｆ１２は、ジョブＦ、Ｇ、Ｈ、Ｉを含み、ジョブＦは開始ジョブ、ジョブＩは最終ジョブであり、実行順序を図の矢印で示している。実行予測時間は、ジョブＦ、Ｇ、Ｈそれぞれは１０分であり、ジョブＩは５分である。したがって、ジョブフローＦ２の全体実行予測時間は３５分（＝１０＋１０＋１０＋５）となる。

ジョブフローｆ１１、ｆ１２に対し、ジョブフローｆ１１の方がジョブフローｆ１２よりも全体実行予測時間が長いので、２つのジョブフローの内、ジョブフローｆ１１がクリティカルパスとなる。よって、クリティカルパス上のジョブＡ、Ｂ、Ｃ、Ｄ、Ｅの実行優先度は、クリティカルパス上に無いジョブＦ、Ｇ、Ｈ、Ｉの実行優先度よりも高く設定される。

図１２はジョブスケジューリングを示す図である。縦軸はジョブの種別、横軸は時間である。ジョブフローｆ１１、ｆ１２のジョブスケジューリングｊ０を示している。
〔０：００〕ジョブＡ、Ｆの実行が開始される。

〔０：０５〕ジョブＡ、Ｆは実行中である。
〔０：１０〕ジョブＡ、Ｆの実行が終了する。ジョブＢ、Ｇの実行が開始される。
〔０：１５〕ジョブＢ、Ｇは実行中である。

〔０：２０〕ジョブＢ、Ｇの実行が終了する。ジョブＣ、Ｄ、Ｈの実行が開始される。
〔０：２５〕ジョブＣ、Ｈは実行中である。ジョブＤの実行が終了する。
〔０：３０〕ジョブＣ、Ｈの実行が終了する。ジョブＥ、Ｉの実行が開始される。

〔０：３５〕ジョブＥは実行中である。ジョブＨの実行が終了する。
〔０：４０〕ジョブＥの実行が終了する。
上記のジョブスケジューリングｊ０では、システム多重度の制約がないとし、実行予測時間と実際の実行時間が等しい。このため、０：００からジョブフローｆ１１、ｆ１２を共に実行した場合、ジョブフローｆ１１の全体実行予測時間は４０分であるから、ちょうど０：４０でジョブフローｆ１１の実行が終了している。また、ジョブフローｆ１２の全体実行予測時間は３５分であるから、ちょうど０：３５でジョブフローｆ１２の実行が終了している。

次に条件＃１におけるクリティカルパス評価について説明する。クリティカルパス上のジョブの実際の実行時間が実行予測時間より短くなり（実行予測時間＞実際の実行時間）、ジョブ終了時にクリティカルパスが評価される例である。

図１３はジョブスケジューリングを示す図である。縦軸はジョブの種別、横軸は時間である。図１２の状態から、クリティカルパス上のジョブＡ、Ｂの実際の実行時間が実行予測時間よりも５分短くなった場合のジョブスケジューリングｊ１を示している。

〔０：００〕ジョブＡ、Ｆの実行が開始される。
〔０：０５〕ジョブＡの実行が終了する。ジョブＢの実行が開始される。ジョブＦは実行中である。

〔０：１０〕ジョブＢ、Ｆの実行が終了する。ジョブＧの実行が開始される。
〔０：１５〕ジョブＧは実行中である。
〔０：２０〕ジョブＣ、Ｄ、Ｈの実行が開始される。ジョブＧの実行が終了する。

〔０：２５〕ジョブＣ、Ｈは実行中である。ジョブＤの実行が終了する。
〔０：３０〕ジョブＣ、Ｈの実行が終了する。ジョブＥ、Ｉの実行が開始される。
〔０：３５〕ジョブＥは実行中である。ジョブＩの実行が終了する。

〔０：４０〕ジョブＥの実行が終了する。
上記のジョブスケジューリングｊ１では、ジョブＡ、Ｂの実際の実行時間が実行予測時間よりも短いので、ジョブＢのジョブ実行終了時（０：１０）にクリティカルパスの評価が行われる。

ここで、ジョブＢのジョブ実行終了時（０：１０）におけるクリティカルパス評価を説明する前に、クリティカルパス評価を行わなかった場合のジョブスケジューリングについて説明する。

図１４はジョブスケジューリングを示す図である。縦軸はジョブの種別、横軸は時間である。ジョブＢの終了時点（０：１０）では、次に実行するジョブとしてジョブＣ、Ｄ、Ｇが候補に挙げられる。図１４は、ジョブＣ、Ｄ、Ｇの候補のうち、元のクリティカルパスで優先されていたジョブＣ、Ｄをそのまま実行した場合のジョブスケジューリングｊ１ａを示している。

〔０：００〕ジョブＡ、Ｆの実行が開始される。
〔０：０５〕ジョブＡの実行が終了する。ジョブＢの実行が開始される。ジョブＦは実行中である。

〔０：１０〕ジョブＢ、Ｆの実行が終了する。ジョブＣ、Ｄの実行が開始される。
〔０：１５〕ジョブＣは実行中である。ジョブＤの実行が終了する。ジョブＧの実行が開始される。

〔０：２０〕ジョブＣの実行が終了する。ジョブＥの実行が開始される。ジョブＧは実行中である。
〔０：２５〕ジョブＥは実行中である。ジョブＧの実行が終了する。ジョブＨの実行が開始される。

〔０：３０〕ジョブＥの実行が終了する。ジョブＨは実行中である。
〔０：３５〕ジョブＨの実行が終了する。ジョブＩの実行が開始される。
〔０：４０〕ジョブＩの実行が終了する。

ここで、ジョブＢの終了時点（０：１０）において、次に実行するジョブＣ、Ｄ、Ｇの候補のうち、元のクリティカルパス上で優先度の高かったジョブＣ、Ｄを実行すると、ジョブＧの起動が遅れることになる。

すなわち、ジョブスケジューリングｊ１では、ジョブＧの実行開始時刻は０：１０であったが、ジョブスケジューリングｊ１ａでは、ジョブＧの実行開始時刻は０：１５となっている。

すると、ジョブＧの後続であるジョブＨ、Ｉの実行開始時および実行終了時刻も遅延することになる。すなわち、ジョブスケジューリングｊ１では、ジョブＨの（実行開始時刻、実行終了時刻）は（０：２０、０：３０）であったが、ジョブスケジューリングｊ１ａでは、ジョブＨの（実行開始時刻、実行終了時刻）は（０：２５、０：３５）となっている。

また、ジョブスケジューリングｊ１では、ジョブＩの（実行開始時刻、実行終了時刻）は（０：３０、０：３５）であったが、ジョブスケジューリングｊ１ａでは、ジョブＩの（実行開始時刻、実行終了時刻）は（０：３５、０：４０）となっている。

次にジョブＢのジョブ実行終了時（０：１０）においてクリティカルパス評価を行ったジョブスケジューリングについて説明する。図１４のジョブスケジューリングｊ１ａを見ると、ジョブＢが終了した時点（０：１０）では、実際にはクリティカルパスである最遅延経路は、ジョブＧ、Ｈ、Ｉのルートに移っていることがわかる。

そこで、ジョブＧ、Ｈ、Ｉの遅延を防止するために、ジョブＢの終了時点にて、ジョブＧ、Ｈ、Ｉの実行予測時間にもとづいて、ジョブＢの終了時以降のスケジュールを評価する。

図１５は評価後の新しいクリティカルパスを示す図である。ジョブフローｆ１１−１において、ジョブＡ、Ｂ、Ｃ、Ｄ、Ｅの実行予測時間は当初、ジョブＡ、Ｂ、Ｃ、Ｅそれぞれは１０分であり、ジョブＤは５分であったが、実際には、ジョブＡ、Ｂの実行時間が５分となっている。したがって、ジョブＢの終了時点（０：１０）における、残りのジョブの実行予測時間の積算では、ジョブＣ、Ｅの積算値は２０分（＝１０＋１０）となる。

また、ジョブフローｆ１２−１において、ジョブＢの終了時点（０：１０）における、残りのジョブの実行予測時間の積算では、ジョブＧ、Ｈ、Ｉの２５分（＝１０＋１０＋５）である。

残りのジョブの実行予測時間の比較を行うことで、ジョブＧ、Ｈ、Ｉのフローの方が、ジョブＣ、Ｅのフローよりも実行時間が長いことが認識できる。したがって、ジョブＧ、Ｈ、Ｉのジョブを新たなクリティカルパス上のジョブとし、ジョブＧ、Ｈ、Ｉの優先度を、ジョブＣ、Ｅよりも上げて実行する。このようなクリティカルパスの評価およびクリティカルパスの再設定を行うことで、システム全体のスケジュールに影響を及ぼすジョブ実行の遅延の発生を抑制することができる。

図１６はジョブスケジューリングを示す図である。縦軸はジョブの種別、横軸は時間である。ジョブＢの終了時点（０：１０）でクリティカルパス評価を行った場合のジョブスケジューリングｊ１ｂを示している。

〔０：００〕ジョブＡ、Ｆの実行が開始される。
〔０：０５〕ジョブＡの実行が終了する。ジョブＢの実行が開始される。ジョブＦは実行中である。

〔０：１０〕ジョブＢ、Ｆの実行が終了する。ジョブＣ、Ｇの実行が開始される。
〔０：１５〕ジョブＣ、Ｇは実行中である。
〔０：２０〕ジョブＣ、Ｇの実行が終了する。ジョブＤ、Ｈの実行が開始される。

〔０：２５〕ジョブＤの実行が終了する。ジョブＥの実行が開始される。ジョブＨは実行中である。
〔０：３０〕ジョブＥは実行中である。ジョブＨの実行が終了する。ジョブＩの実行が開始される。

〔０：３５〕ジョブＥの実行が終了する。ジョブＩの実行が終了する。
上記のジョブスケジューリングｊ１ｂのように、ジョブＢの終了時点で、クリティカルパスを評価してクリティカルパスの最適化を行い、ジョブＧを実行することで、ジョブＧ、Ｈ、Ｉの実行開始時刻および実行終了時刻の遅延を抑制することが可能になる。

次に条件＃２におけるクリティカルパス評価について説明する。ジョブ実行開始時に、クリティカルパス上にないジョブの実際の実行時間が実行予測時間より長くなり（実行予測時間＜実際の実行時間）、ジョブ終了時にクリティカルパスが評価される例である。

図１７はジョブスケジューリングを示す図である。縦軸はジョブの種別、横軸は時間である。当初のクリティカルパス上にないジョブＦの実行時間が、実行予測時間よりも長くなった場合（１０分長くなった場合）のジョブスケジューリングｊ２を示している。

〔０：００〕ジョブＡ、Ｆの実行が開始される。
〔０：０５〕ジョブＡ、Ｆは実行中である。
〔０：１０〕ジョブＡの実行が終了する。ジョブＢ、Ｇの実行が開始される。ジョブＦは実行中である。

〔０：１５〕ジョブＢ、Ｆ、Ｇは実行中である。
〔０：２０〕ジョブＢ、Ｆ、Ｇの実行が終了する。ジョブＣ、Ｄ、Ｈの実行が開始される。

〔０：２５〕ジョブＣ、Ｈは実行中である。ジョブＤの実行が終了する。
〔０：３０〕ジョブＣ、Ｈの実行が終了する。ジョブＥ、Ｉの実行が開始される。
〔０：３５〕ジョブＥは実行中である。ジョブＩの実行が終了する。

〔０：４０〕ジョブＥの実行が終了する。
上記のジョブスケジューリングｊ２では、当初クリティカルパス上にないジョブＦの実行時間が実行予測時間よりも長いので、クリティカルパスの評価は、ジョブＦの実行終了時点（０：２０）にて行われることになる。

ここで、ジョブＦのジョブ実行終了時（０：２０）におけるクリティカルパス評価を説明する前に、クリティカルパス評価を行わなかった場合について説明する。
図１８はジョブスケジューリングを示す図である。縦軸はジョブの種別、横軸は時間である。ジョブＦの終了時点（０：２０）では、次に実行するジョブとしてはジョブＣ、Ｄ、Ｇが候補に挙げられる。図１８では、ジョブＣ、Ｄ、Ｇの候補のうち、元のクリティカルパスで優先されていたジョブＣ、Ｄをそのまま実行した場合のジョブスケジューリングｊ２ａを示している。

〔０：００〕ジョブＡ、Ｆの実行が開始される。
〔０：０５〕ジョブＡ、Ｆは実行中である。
〔０：１０〕ジョブＡの実行が終了する。ジョブＢの実行が開始される。ジョブＦは実行中である。

〔０：１５〕ジョブＢ、Ｆは実行中である。
〔０：２０〕ジョブＢ、Ｆの実行が終了する。ジョブＣ、Ｄの実行が開始される。
〔０：２５〕ジョブＣは実行中である。ジョブＤの実行が終了する。ジョブＧの実行が開始される。

〔０：３０〕ジョブＣの実行が終了する。ジョブＥの実行が開始される。ジョブＧは実行中である。
〔０：３５〕ジョブＥは実行中である。ジョブＧの実行が終了する。ジョブＨの実行が開始される。

〔０：４０〕ジョブＥの実行が終了する。ジョブＨは実行中である。
〔０：４５〕ジョブＨの実行が終了する。ジョブＩの実行が開始される。
〔０：５０〕ジョブＩの実行が終了する。

ここで、ジョブＦの終了時点（０：２０）において、次に実行するジョブＣ、Ｄ、Ｇの候補のうち、元のクリティカルパス上で優先度の高かったジョブＣ、Ｄを実行すると、ジョブＧの起動が遅れることになる。

すなわち、ジョブスケジューリングｊ２では、ジョブＧの実行開始時刻は０：１０であったが、ジョブスケジューリングｊ２ａでは、ジョブＧの実行開始時刻は０：２５となっている。

すると、ジョブＧの後続であるジョブＨ、Ｉの実行開始時および実行終了時刻も遅延することになる。すなわち、ジョブスケジューリングｊ２では、ジョブＨの（実行開始時刻、実行終了時刻）は（０：２０、０：３０）であったが、ジョブスケジューリングｊ２ａでは、ジョブＨの（実行開始時刻、実行終了時刻）は（０：３５、０：４５）となっている。

また、ジョブスケジューリングｊ２では、ジョブＩの（実行開始時刻、実行終了時刻）は（０：３０、０：３５）であったが、ジョブスケジューリングｊ２ａでは、ジョブＩの（実行開始時刻、実行終了時刻）は（０：４５、０：５０）となっている。

次にジョブｆ１２のジョブ実行終了時（０：２０）におけるクリティカルパス評価を行う場合について説明する。ジョブスケジューリングｊ２ａを見ると、ジョブＦが終了した時点で実際には、クリティカルパスである最遅延経路は、ジョブＧ、Ｈ、Ｉのルートに移っていることがわかる。

そこで、ジョブＧ、Ｈ、Ｉの遅延を防止するために、ジョブＦの終了時点にて、ジョブＧ、Ｈ、Ｉの実行予測時間にもとづいて、ジョブＦの終了時以降のスケジュールを評価する。

図１９は評価後の新しいクリティカルパスを示す図である。ジョブフローｆ１１−２において、ジョブＦの終了時点（０：２０）における、残りのジョブの実行予測時間の積算では、ジョブＣ、Ｄ、Ｅの積算値は２０分（＝１０＋１０）となる。

一方、ジョブフローｆ１２−２において、ジョブＦの実行予測時間は当初１０分であったが、実際には、実行時間が２０分となっている。したがって、ジョブＦの終了時点（０：２０）における、残りのジョブの実行予測時間の積算は、ジョブＧ、Ｈ、Ｉの２５分（＝１０＋１０＋５）となる。

残りのジョブの実行予測時間の比較を行うことで、ジョブＧ、Ｈ、Ｉのフローの方が、ジョブＣ、Ｅのフローよりも実行予測時間が長いことが認識できる。したがって、ジョブＧ、Ｈ、Ｉのジョブを新たなクリティカルパス上のジョブとし、ジョブＧ、Ｈ、Ｉの優先度を、ジョブＣ、Ｅよりも上げて実行する。このようなクリティカルパス評価およびクリティカルパスの再設定を行うことで、システム全体のスケジュールに影響を及ぼすジョブ実行の遅延の発生を抑制することができる。

図２０はジョブスケジューリングを示す図である。縦軸はジョブの種別、横軸は時間である。ジョブＦの終了時点（０：２０）でクリティカルパス評価を行った場合のジョブスケジューリングｊ２ｂを示している。

〔０：００〕ジョブＡ、Ｆの実行が開始される。
〔０：０５〕ジョブＡ、Ｆは実行中である。
〔０：１０〕ジョブＡの実行が終了する。ジョブＢの実行が開始される。ジョブＦは実行中である。

〔０：１５〕ジョブＢ、Ｆは実行中である。
〔０：２０〕ジョブＢ、Ｆの実行が終了する。ジョブＣ、Ｇの実行が開始される。
〔０：２５〕ジョブＣ、Ｇは実行中である。

〔０：３０〕ジョブＣ、Ｇの実行が終了する。ジョブＤ、Ｈの実行が開始される。
〔０：３５〕ジョブＤの実行が終了する。ジョブＥの実行が開始される。ジョブＨは実行中である。

〔０：４０〕ジョブＥは実行中である。ジョブＨの実行が終了する。ジョブＩの実行が開始される。
〔０：４５〕ジョブＥ、Ｉの実行が終了する。

上記のジョブスケジューリングｊ２ｂのように、ジョブＦの終了時点でクリティカルパスを評価してクリティカルパスの最適化を行い、ジョブＧを実行することで、クリティカルパスの最適化を行う。これにより、ジョブＧ、Ｈ、Ｉの実行開始時刻および実行終了時刻の遅延を抑制することが可能になる。

次にジョブ管理サーバ２の各構成要素の動作についてフローチャートを用いて説明する。図２１はピーク実行日登録部の動作を示すフローチャートである。
〔Ｓ１〕ピーク実行日登録部１３は、ピーク実行日がユーザインタフェース部４０を介して入力されたか否かを判断する。すなわち、ジョブの通常実行日の中で、ピーク実行日として選択されている日付があるか否かを判断する。ピーク実行日の入力があればステップＳ２へ行き、入力がなければ終了する。

〔Ｓ２〕ピーク実行日登録部１３は、ピーク実行日を情報管理部３０内のテーブルに登録する。
図２２はクリティカルパス設定部の動作を示すフローチャートである。

〔Ｓ１１〕クリティカルパス設定部１４は、ジョブフロー定義テーブルＴ１を参照して、所定期間内の全ジョブフローの中の最終ジョブを検出する。なお、最終ジョブとは、自身が他ジョブから先行ジョブとして設定されていないジョブである。

〔Ｓ１２〕クリティカルパス設定部１４は、検出した最終ジョブからジョブフローを逆にたどり、各ジョブに対して、予測積算実行時間を設定する。
〔Ｓ１３〕クリティカルパス設定部１４は、当該ジョブフローに対して、終了予定時刻（dead line）が設定されているか否かを判断する。終了予定時刻が設定されている場合はステップＳ１４へ行き、設定されていない場合はステップＳ１５へ行く。

〔Ｓ１４〕クリティカルパス設定部１４は、クリティカルパス以外のジョブに対して、終了予定時刻にジョブ実行が終わるまでにどれぐらい遅延可能であるかの遅延猶予時間をジョブ毎に算出する。

例えば、現時刻から１時間後に終了しなければならないジョブフローがあって、該１時間以内であればどこの時間帯でも終了してよいジョブＡがあるとする。また、ジョブＡのジョブ実行時間が１０分であるとする。この場合、ジョブＡは、現時刻から５０分後に実行を開始すれば、１時間以内でジョブＡの実行処理が完了するから、ジョブＡの現時刻からの猶予時間は５０分となる。

〔Ｓ１５〕クリティカルパス設定部１４は、ジョブ定義テーブルＴ２の「クリティカルパス上の有無」に“ＯＮ（有）”を登録し、「終了予定時刻のあるジョブ」に当該ジョブの“ジョブ名”と“実行実績時間”を登録する。

なお、実行実績時間は、実行日がピーク実行日であるか否かを判断し、実行日がピーク実行日ならばピーク時における実行予測時間を設定し、実行日がピーク実行日でないならば前回の実行実績時間を設定する。

上記の動作フローは、所定期間の実行予定のあるすべてのジョブの中で、終了予定時刻があるジョブに対して繰り返し実行される。
図２３は優先度設定部の動作を示すフローチャートである。

〔Ｓ２１〕優先度設定部１６は、現在すでにジョブを実行している場合は、システム多重度から実行済ジョブの数を減算する。
〔Ｓ２２〕優先度設定部１６は、クリティカルパス上にあるジョブを認識して、該クリティカルパス上の先頭ジョブを基準ジョブと設定する。

〔Ｓ２３〕優先度設定部１６は、基準ジョブの実行時間内で実行される他のジョブの数をカウントする。例えば、基準ジョブの実行時間が１０分であり、その１０分間の時間範囲内で実行予定のあるジョブが３つあるならば、カウント数は３となる。

〔Ｓ２４〕優先度設定部１６は、システム多重度−１の数が、カウントしたジョブ数未満であるか否かを判断する。（システム多重度−１）＜（カウントしたジョブ数）の場合はステップＳ２６へ行き、（システム多重度−１）≧（カウントしたジョブ数）の場合はステップＳ２５へ行く。

なお、（システム多重度−１）＜（カウントしたジョブ数）は、システム多重度を超える数の実行予定ジョブが所定時間内に登録されている場合を示す。また、（システム多重度−１）≧（カウントしたジョブ数）は、所定時間内における実行予定ジョブの数が、システム多重度以内である場合を示す。

〔Ｓ２５〕優先度設定部１６は、当該基準ジョブは現システム多重度で実行可能であると認識する。そして、優先度設定部１６は、当該基準ジョブの次に実行予定のジョブをあらたな基準ジョブとして設定し、ステップＳ２２の処理へ戻る。次に基準となる後続ジョブがない場合はステップＳ３１へ行く。

〔Ｓ２６〕優先度設定部１６は、終了時刻のあるジョブの終了までの他時間帯の多重度を求める。
〔Ｓ２７〕優先度設定部１６は、実行対象ジョブの内でクリティカルパス以外のジョブに対して、該ジョブが有する猶予時間の時間帯を認識する。そして、優先度設定部１６は、該時間帯内において、現在のシステム多重度にもとづいてジョブが実行可能否かを判断する。ジョブが実行不可能ならばステップＳ２８へ行き、実行可能ならばステップＳ２９へ行く。

〔Ｓ２８〕優先度設定部１６は、クリティカルパス以外の次のジョブの猶予時間の時間帯のシステム多重度以内での実行可否を判断する（クリティカルパス以外のすべてのジョブに実施する）。いずれかの時間帯で実行可能ならばステップＳ２９へ行き、どの時間帯にも実行不可能ならばステップＳ３０へ行く。

〔Ｓ２９〕優先度設定部１６は、システム多重度を超えたジョブの開始時刻をシステム多重度以内で実行可能な時刻へ変更し、優先度を下げて設定する。
〔Ｓ３０〕優先度設定部１６は、システム多重度を超えたジョブの開始時刻を終了予定時刻のあるジョブ終了後に変更し、優先度を下げて設定する。

〔Ｓ３１〕優先度設定部１６は、優先度を実行依頼部１７へ送信する。実行依頼部１７では、優先度にもとづいてジョブの実行依頼を出力する。
図２４は実行実績時間算出部の動作を示すフローチャートである。

〔Ｓ４１〕実行実績時間算出部１８は、ジョブ実行の開始時刻を取得する。
〔Ｓ４２〕実行実績時間算出部１８は、ジョブを実行する際のシステム多重度数を更新する。例えば、ジョブＡが実行されている所定時間内でジョブＢを実行するような場合、システム多重度を１から２へインクリメントして更新する。

〔Ｓ４３〕実行実績時間算出部１８は、ジョブ実行制御部２０でジョブが実行されて終了すると、ジョブを終了する際のシステム多重度を更新する。例えば、ジョブＡ、Ｂが実行されている所定時間内でジョブＢの実行が終了した場合、システム多重度を２から１へデクリメントして更新する。

〔Ｓ４４〕実行実績時間算出部１８は、ジョブの終了時刻を取得する。
〔Ｓ４５〕実行実績時間算出部１８は、ジョブの開始時刻と終了時刻との差分を算出する。

〔Ｓ４６〕実行実績時間算出部１８は、ジョブの実行日がピーク実行日であるか否かを判断する。ピーク実行日ならばステップＳ４７へ行き、ピーク実行日でないならステップＳ４８へ行く。

〔Ｓ４７〕実行実績時間算出部１８は、情報管理部３０内のテーブルにピーク時の実行実績時間を登録する。
〔Ｓ４８〕実行実績時間算出部１８は、情報管理部３０内のテーブルに前回の実行実績時間を登録する。

図２５はクリティカルパス評価部の動作を示すフローチャートである。
〔Ｓ５１〕クリティカルパス評価部１９は、ジョブ定義テーブルＴ２に登録されるジョブがクリティカルパス上のジョブであるか否かを判断する。クリティカルパス上のジョブならばステップＳ５２へ行き、クリティカルパス上のジョブでないならばステップＳ５４へ行く。

〔Ｓ５２〕クリティカルパス評価部１９は、後続ジョブの開始時刻と終了予定時刻の変更を行う。
〔Ｓ５３〕クリティカルパス評価部１９は、終了予定時刻が実際のジョブの実行時間未満であるか否かを判断する。（終了予定時刻）＞（実際のジョブの実行時間）の場合はステップＳ５５へ行き、（終了予定時刻）≦（実際のジョブの実行時間）の場合は終了する。

〔Ｓ５４〕クリティカルパス評価部１９は、終了予定時刻が実際のジョブの実行時間未満であるか否かを判断する。（終了予定時刻）＜（実際のジョブの実行時間）の場合はステップＳ５５へ行き、（終了予定時刻）≧（実際のジョブの実行時間）の場合は終了する。

〔Ｓ５５〕クリティカルパス評価部１９は、クリティカルパスの評価を行い、クリティカルパスの再設定をクリティカルパス設定部１４に指示する。
以上説明したように、本技術では、クリティカルパスの変化を検出して、ジョブの実行優先度を動的に変更（高→低、低→高）させることとした。また、優先度の再設定においては、クリティカルパスの評価を行って判断する。

従来では、クリティカルパス上にないジョブについては、優先度を付けて実行する判断基準がなく、クリティカルパス上にあるジョブへの影響を事前に見積もることが困難であった。これに対し、本技術では、クリティカルパス上にないジョブについても優先度をつけて実行するので、システム全体のスケジュールのジョブ実行の遅延を防止することが可能になる。

また、システムリソースの範囲内で高優先度にして実行するジョブ、または低優先度にして実行を遅らせるジョブを、ジョブ実行／終了の度に適応的にフィードバックして設定することができる。さらに、バッチ処理の進行に伴い刻々と変化するシステムの動作状況に合わせた効率の良いジョブスケジューリングが可能になる。

さらにまた、ジョブの実行時間の変動について、前回履歴を参照する、あるいはジョブの直前の入力データ量から予測するだけではなく、特異日（ピーク実行日）の変動にも対応することにより、サーバリソースを効率よく使用して、より正確にジョブの実行時間帯を予測することが可能になる。

次に本技術をコンピュータによって実現する場合について説明する。上記に示した処理機能は、コンピュータによって実現可能である。図２６は本実施の形態に用いるコンピュータのハードウェアの一構成例を示す図である。図１の情報処理装置１内のコンピュータ１００は、ＣＰＵ１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０８を介してＲＡＭ（Random Access Memory）１０２と複数の周辺機器が接続されている。

ＲＡＭ１０２は、コンピュータ１００の主記憶装置として使用される。ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳのプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。

バス１０８に接続されている周辺機器としては、ＨＤＤ（Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、および通信インタフェース１０７がある。

ＨＤＤ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、コンピュータ１００の二次記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、二次記憶装置としては、フラッシュメモリなどの半導体記憶装置を使用することもできる。

グラフィック処理装置１０４には、モニタ１０４ａが接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１０４ａの画面に表示させる。モニタ１０４ａとしては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。

入力インタフェース１０５には、キーボード１０５ａとマウス１０５ｂとが接続されている。入力インタフェース１０５は、キーボード１０５ａやマウス１０５ｂから送られてくる信号をＣＰＵ１０１に送信する。なお、マウス１０５ｂは、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク１０６ａに記録されたデータの読み取りを行う。光ディスク１０６ａは、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク１０６ａには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（Rewritable）などがある。

通信インタフェース１０７は、ネットワーク１１０に接続されている。通信インタフェース１０７は、ネットワーク１１０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。

以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。また、コンピュータで本実施の形態の処理機能を実現する場合、図１の情報処理装置１が有する機能の処理内容を記述したプログラムが提供される。

そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ／ＲＷなどがある。光磁気記録媒体には、ＭＯ（Magneto Optical disk）などがある。なおプログラムを記録する記録媒体には、一時的な伝搬信号自体は含まれない。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

また、上記の処理機能の少なくとも一部を、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現することもできる。

以上説明したように、本技術によれば、ジョブの自動運用において、動的にジョブの実行優先度を決定するので、優先度の高いジョブは遅延なく実行させることができ、ジョブ実行の遅延を抑制することが可能になる。

また、様々なジョブを運用しているシステムでは、各々のジョブの実行時間を予測するために、従来では、担当者がジョブの内容そのものに精通していることや、システム全体のジョブスケジュールを精通していることが求められていた。

しかし、多くのジョブを運用しているシステムでは、ジョブの内容把握だけでも膨大な作業であり、また、一部のジョブの遅れや、ジョブの早期終了により、システムの運用状況は、ジョブ実行計画立案時の状況から刻々と変化する。

これに対し、本技術によれば、動的にジョブの優先度を決定し、スケジュールするので、ジョブの内容に精通していなくとも、システム全体のジョブ実行を遅延なくスケジュールすることが実現可能である。また、リソース不足が仮に生じたような場合であっても、ジョブ実行時間に生じる遅延時間を最小にすることが可能になる。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。

１ 情報処理装置
１ａ 保持手段
１ｂ ジョブスケジューリング手段
ａ１、ａ２ ジョブ
Ｈ０ 時間範囲
Ｈ１ 第１の期間
Ｈ２ 第２の期間

Claims (8)

1. 複数のジョブそれぞれについて、第１の期間内での実行に要する第１の実行予測時間と、第２の期間内での実行に要する、前記第１の実行予測時間よりも長い第２の実行予測時間と、を保持する保持手段と、
   前記複数のジョブのうちの複数の実行予定ジョブそれぞれの実行開始時刻が前記第１の期間と前記第２の期間とのどちらに含まれるのかにもとづいて、前記複数の実行予定ジョブそれぞれの実行予測時間を決定し、決定した実行予測時間にもとづき前記複数の実行予定ジョブのスケジューリングを行うジョブスケジューリング手段と、
   前記スケジューリングに従って、前記複数の実行予定ジョブを実行するジョブ実行制御手段と、
   を備え、
   前記ジョブスケジューリング手段は、前記複数の実行予定ジョブの実行順が示された複数のジョブフローの中で、開始ジョブから最終ジョブまでの実行に要する時間が最大の第１のジョブフローを判定し、
   前記ジョブ実行制御手段は、前記第１のジョブフローに含まれる第１の実行予定ジョブを、前記第１のジョブフローに含まれない第２の実行予定ジョブよりも優先して実行し、
   前記ジョブスケジューリング手段は、前記第１の実行予定ジョブが実行された結果、実行時間が実行予測時間より短かった場合、前記複数のジョブフローの中で、未処理のジョブの先頭のジョブから最終ジョブまでの実行に要する時間が最大の第２のジョブフローを判定し、
   前記ジョブ実行制御手段は、前記第２のジョブフローに含まれる未処理の第３の実行予定ジョブの優先度を、前記第２のジョブフローに含まれない未処理の第４の実行予定ジョブよりも優先して実行する、
   ことを特徴とする情報処理装置。
2. 前記ジョブスケジューリング手段は、
   ジョブの実行開始時刻が、前記第１の期間に含まれる場合は前記第１の実行予測時間を選択し、
   ジョブの実行開始時刻が、前記第２の期間に含まれる場合は前記第２の実行予測時間を選択することを特徴とする請求項１記載の情報処理装置。
3. 前記ジョブスケジューリング手段は、
   ユーザから指定された、通常日を前記第１の期間、前記通常日よりも業務が繁忙となるピーク日を前記第２の期間とし、
   前記通常日における過去のジョブの実行実績時間を前記第１の実行予測時間とし、
   前記ピーク日に予測される、前記実行実績時間よりも長く設定された実行予測時間を前記第２の実行予測時間とすることを特徴とする請求項２記載の情報処理装置。
4. 前記ジョブスケジューリング手段は、前記第１の実行予定ジョブが実行された結果、実行時間が実行予測時間より短かった場合、または前記第２の実行予定ジョブが実行された結果、実行時間が実行予測時間より長かった場合に、前記第２のジョブフローを判定することを特徴とする請求項１記載の情報処理装置。
5. 前記ジョブスケジューリング手段は、
   前記第１のジョブフローの判定の際には、前記複数のジョブフローそれぞれに含まれるジョブの実行予定時間を積算することで、前記複数のジョブフローそれぞれの開始ジョブから最終ジョブまでの実行に要する時間を計算し、
   前記第２のジョブフローの判定の際には、前記複数のジョブフローそれぞれに含まれる未処理のジョブの実行予定時間を積算することで、前記複数のジョブフローそれぞれの未処理のジョブの先頭のジョブから最終ジョブまでの実行に要する時間を計算する、
   ことを特徴とする請求項１記載の情報処理装置。
6. 前記ジョブスケジューリング手段は、前記実行予定ジョブのスケジューリングにおいて、前記第１のジョブフローに含まれる前記第１の実行予定ジョブを実行する予定の時間帯に、前記第２の実行予定ジョブの実行予定があり、実行予定の前記第２の実行予定ジョブを予定通り実行すると、前記時間帯に並列実行するジョブの個数があらかじめ設定した多重度を超える場合、並列に実行するジョブの個数が前記多重度を超えない時間帯に実行予定の前記第２の実行予定ジョブの実行時間帯を移動することを特徴とする請求項１記載の情報処理装置。
7. コンピュータが、
   複数のジョブそれぞれについて、第１の期間内での実行に要する第１の実行予定時間と、第２の期間内での実行に要する、前記第１の実行予定時間よりも長い第２の実行予定時間とをメモリに保持し、
   前記複数のジョブのうちの複数の実行予定ジョブそれぞれの実行開始時刻が前記第１の期間と前記第２の期間とのどちらに含まれるのかにもとづいて、前記複数の実行予定ジョブそれぞれの実行予測時間を決定し、決定した実行予測時間にもとづきジョブのスケジューリングを行い、
   前記スケジューリングに従って、前記複数の実行予定ジョブを実行し、
   ジョブスケジューリングの際には、前記複数の実行予定ジョブの実行順が示された複数のジョブフローの中で、開始ジョブから最終ジョブまでの実行に要する時間が最大の第１のジョブフローを判定し、
   前記複数の実行予定ジョブを実行の際には、前記第１のジョブフローに含まれる第１の実行予定ジョブを、前記第１のジョブフローに含まれない第２の実行予定ジョブよりも優先して実行し、
   前記第１の実行予定ジョブが実行された結果、実行時間が実行予測時間より短かった場合、前記複数のジョブフローの中で、未処理のジョブの先頭のジョブから最終ジョブまでの実行に要する時間が最大の第２のジョブフローを判定し、
   前記第２のジョブフローに含まれる未処理の第３の実行予定ジョブの優先度を、前記第２のジョブフローに含まれない未処理の第４の実行予定ジョブよりも優先して実行する、
   ことを特徴とするジョブスケジューリング方法。
8. メモリが、複数のジョブそれぞれについて、第１の期間内での実行に要する第１の実行予定時間と、第２の期間内での実行に要する、前記第１の実行予定時間よりも長い第２の実行予定時間とを保持し、
   プロセッサが、
   前記複数のジョブのうちの複数の実行予定ジョブそれぞれの実行開始時刻が前記第１の期間と前記第２の期間とのどちらに含まれるのかにもとづいて、前記複数の実行予定ジョブそれぞれの実行予測時間を決定し、決定した実行予測時間にもとづきジョブのスケジューリングを行い、
   前記スケジューリングに従って、前記複数の実行予定ジョブを実行し、
   ジョブスケジューリングの際には、前記複数の実行予定ジョブの実行順が示された複数のジョブフローの中で、開始ジョブから最終ジョブまでの実行に要する時間が最大の第１のジョブフローを判定し、
   前記複数の実行予定ジョブを実行の際には、前記第１のジョブフローに含まれる第１の実行予定ジョブを、前記第１のジョブフローに含まれない第２の実行予定ジョブよりも優先して実行し、
   前記第１の実行予定ジョブが実行された結果、実行時間が実行予測時間より短かった場合、前記複数のジョブフローの中で、未処理のジョブの先頭のジョブから最終ジョブまでの実行に要する時間が最大の第２のジョブフローを判定し、
   前記第２のジョブフローに含まれる未処理の第３の実行予定ジョブの優先度を、前記第２のジョブフローに含まれない未処理の第４の実行予定ジョブよりも優先して実行する、
   処理を、前記メモリおよび前記プロセッサを含むコンピュータに実行させることを特徴とするジョブスケジューリングプログラム。
   

Images