JP3559581B2

JP3559581B2 - Job execution control method

Info

Publication number: JP3559581B2
Application number: JP33975793A
Authority: JP
Inventors: 弘文長須賀; 利明新井; 壮一尾山; 雅広清井
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1993-12-06
Filing date: 1993-12-06
Publication date: 2004-09-02
Anticipated expiration: 2019-09-02
Also published as: JPH07160517A

Description

【０００１】
【産業上の利用分野】
計算機システムのジョブスケジュール方法に係り、特にジョブの実行制御方法に関する。
【０００２】
【従来の技術】
計算機の利用形態の一つに、収集した売上げ情報や在庫情報などのデータを１日単位や、１週間単位、１か月単位などにまとめておいて、一括して集計するバッチ処理がある。バッチ集計処理は、いくつかの処理プログラムを実行させることにより、最終的な実行結果を得る体系となっている。
こうした実行結果を得るための論理的な仕事の単位をジョブと呼ぶ。１つのジョブの中では、複数の処理プログラムを実行させ、実行結果を得る。一つのプログラムの実行単位をジョブステップと呼ぶ。
また、こうしたバッチ処理で、実行させるプログラムや、そのプログラムでアクセスするファイルは、ジョブ制御言語（ＪＣＬ）で記述されるジョブ制御文（ＪＣＳ）で定義する。
一般的には、上段のジョブステップの実行結果を下段のジョブステップが参照し、下段のジョブステップの実行結果をさらに下段のジョブステップが参照して処理するプロセスを繰り返すことにより、最終的な実行結果を得る。
このように、複数のジョブステップから構成されているジョブの実行方法は、ＡＮＤＲＥＷＳ．ＴＡＮＥＮＢＡＵＭ著「ＭＯＤＥＲＮＯＰＥＲＡＴＩＮＧＳＹＳＴＥＭＳ」（Ｐｒｅｎｔｉｃｅ−ＨａｌｌＩｎｔｅｒｎａｔｉｏｎａｌＥｄｉｔｉｏｎｓ、Ｐ６〜７）に記載されているように、一般的には、上段のジョブステップから１つずつ順次実行させる方法が一般的である。この場合、各ジョブの実行用に一つのアドレス空間を割当て、その空間上でジョブステップを１段ずつ実行させていた。これにより、多重のアドレス空間を生成し、管理するオペレーティングシステムでは、複数のジョブを並列に実行させることが可能であり、バッチ処理全体の処理時間短縮を臨むことができる。
【０００３】
【発明が解決しようとする課題】
近年、半導体技術等の進歩により、データ演算等をする中央処理装置（ＣＰＵ）や入出力装置の処理能力の進展が目覚ましい。また、ＣＰＵにおいては、多数のＣＰＵを配置し、各ＣＰＵにプログラムの実行を分散させ、処理の並列度を向上させることで、プログラムのスループット向上を図る分散環境の構築が図られている。
しかし、上記従来技術では、ジョブステップの実行スケジュールにおいて、ジョブステップの並列処理ができないことに問題がある。
ここで、ジョブステップ１、ジョブステップ２、およびジョブステップ３という３つのジョブステップから構成されるジョブを例に説明する。ジョブの処理構成は、ジョブステップ１とジョブステップ２の実行結果をジョブステップ３が参照するものとする。従来技術では、ジョブステップ１、ジョブステップ２、ジョブステップ３の順で、順次１段ずつジョブステップを実行させることになる。しかし、ジョブステップ１とジョブステップ２は、データの受け渡し関係が存在しないため、並列に実行することが可能である。
本発明の目的は、１つのジョブの中で、並列に実行させることができるジョブステップを並列実行させることにより、バッチ処理時間の短縮を図ることにある。
【０００４】
【課題を解決するための手段】
上記目的を達成するため、本発明では、
ジョブ制御文（ＪＣＳ）を用いて実行するプログラムと、当該プログラムが使用する資源を指定し、ファイルにアクセスし、複数のジョブステップから構成される複数のジョブが並列あるいは逐次的に実行する計算機システムにおいて、
各ジョブステップについて、実行を開始できる条件である実行開始条件を指定するパラメタをＪＣＳに設け、ジョブが投入されると、当該ジョブを定義したＪＣＳを入力し、前記ジョブの全ての各ジョブステップから、前記パラメタの指定内容が等しいジョブステップと前記指定のないジョブステップの数の合計の最大値を求めることで、並列に実行できるジョブステップの最大値（最大並列度）を求めるステップと、
前記最大並列度の数のプログラムが平行して実行できるための資源を確保するステップと、
前記ジョブの中で、実行開始条件を満たしたジョブステップの実行を許可するステップと、
前記全てのジョブステップの実行状況を監視し、全ての前記ジョブステップが実行を完了した時点で、確保した前記資源を解放するステップを有するようにしている。
また、上記の各ジョブステップの実行を開始できる条件である実行開始条件を指定するパラメタをＪＣＳから求めるために、
ジョブが投入されると、当該ジョブを定義したＪＣＳを入力し、前記ＪＣＳに定義されている各ジョブステップがアクセスするファイル識別子を参照して同一のファイルへアクセスするジョブステップのペアを求めるステップと、
前記ペアとなったジョブステップにおいて、前記ＪＣＳで定義されたジョブステップの実行順序が後となっているジョブステップの実行開始条件として、前記ペアとなったもう一方のジョブステップの実行完了後と定める実行開始条件を決定するステップと、
前記決定した実行開始条件をパラメタとして入力したＪＣＳに書き込むステップを有するようにしている。
また、上記の各ジョブステップの実行を開始できる条件である実行開始条件を指定するパラメタをジョブの実行履歴から求めるために、
ジョブの実行時に該ジョブについて、ジョブの識別子と、ジョブステップの識別子と、ジョブステップの開始時刻と、アクセスした全てのファイル識別子と、アクセスした前記全てのファイルへのアクセスが出力であったか、入力であったかを示すアクセス種別を含む履歴情報を収集するステップと、
同一ジョブ内で、前記ファイル識別子が等しく、かつ、前記アクセス種別が出力と入力であり、かつ、前記アクセス種別が出力であるジョブステップの開始時刻が、前記アクセス種別が入力であるジョブステップの開始時刻より先行しているジョブステップのペアを求めるステップと、
前記アクセス種別が入力であるジョブステップの実行開始条件を、前記アクセス種別が出力であるジョブステップが完了した直後と定める実行開始条件を決定し、保存するステップと、
前記ジョブと同一のジョブが再び投入された時に、前記保存された実行開始条件をパラメタとして入力したＪＣＳに書き込むステップを有するようにしている。
【０００５】
【作用】
ＪＣＳ解析部では、ＪＣＳに指定されたジョブステップの並列実行指定部を抽出し、あるいはＪＣＳに定義されている各ジョブステップでアクセスするファイル情報に基づき並列実行可能部を抽出し、あるいはジョブの実行履歴に基づく並列実行解析の結果と投入されたＪＣＳとをマッチングすることでジョブステップの並列実行可能部を抽出する。
ジョブ実行管理部では、ＪＣＳ解析部から通知された並列度をもとに、並列実行するために必要となるアドレス空間等の資源を確保し、ジョブステップをジョブとして各アドレス空間に割当てて実行させる。各ジョブステップの実行は、ジョブ実行管理部が管理し、実行完了後、ジョブ受付部を経由して、ユーザに実行完了が通知される。
履歴情報収集部では、ジョブの実行履歴情報をファイルのアクセス履歴情報を時系列に収集する。履歴情報解析部では、ファイルへのアクセス履歴情報をもとに、並列実行が可能なジョブステップを求める。
これにより、ジョブにおける並列実行が可能なジョブステップが抽出され、これらのジョブステップを並列実行することができる。
【０００６】
【実施例】
実施例を用いて、本発明を説明する。
第１の実施例は、複数のジョブステップから構成されるジョブにおいて、ジョブで実行させるプログラムやアクセスするファイルを定義するジョブ制御文において、各ジョブステップの開始を宣言するレコードに、ジョブステップが実行を開始できる条件を記述して、１つのジョブ内のジョブステップを並列実行させるものであり、この場合、上記レコードに事前に上記条件を記述しておくか、投入されたジョブ制御文を解析し、ファイルのアクセス順序関係に制約のないジョブステップを抽出して、各ジョブステップの開始を宣言するレコードに、ジョブステップが開始できる条件を付加する。
第２の実施例は、投入されたジョブのジョブ制御文と、以前に実行されたジョブの実行履歴とファイルへのアクセス履歴を照合して、ジョブステップが実行を開始できる条件を、ジョブ制御文に付加することで、ジョブステップを並列実行させる方法である。
【０００７】
図１は本発明の機能ブロック図である。まず、図１を用いて本発明の構成を説明する。
１００は、計算機システムを示す。１００は、演算操作を行なう中央処理装置（ＣＰＵ）（２００）とメモリ（３００）により構成される。４００は外部記憶装置を示す。４００の中には、ジョブで実行させるプログラムやアクセスするファイルを定義したジョブ制御文が格納されている。５００も外部記憶装置である。５００には、履歴情報収集部６０００によって、ジョブの実行履歴情報やファイルへのアクセス履歴情報が出力される。
１０００は、ＪＣＳ解析部である。ＪＣＳ解析部では、投入されたジョブのジョブ制御文（ＪＣＳ）を４００より入力し、ＪＣＳよりファイルへのアクセス順序関係や、各ジョブステップについて実行を開始するための制約条件を求める実行履歴解析部（７０００）の解析結果と照合して、入力したＪＣＳの各ジョブステップについて実行を開始するための制約条件を付加して、ジョブ受付部（２０００）に渡す。
ジョブ受付部では、ＪＣＳ解析部から渡されたＪＣＳについて、ジョブステップを並列実行できる最大の多重度をもとめ、ジョブステップ実行処理部（３０００）にＪＣＳと最大の多重度を渡す。
ジョブステップ実行処理部（３０００）では、並列実行させるために必要な資源（アドレス空間）を確保し、実行開始の制約が解除されたジョブステップから次々と実行させていく。
４０００では、ジョブステップの実行が終了するたびに通知をうけ、通知されたジョブステップが属するジョブが終了したか否かを確認する。終了した場合は、ジョブ完了部５０００に通知し、まだ他のジョブステップに実行を開始していないジョブステップがある場合には、ジョブステップ実行処理部を呼び出す。
６０００は、履歴情報収集部である。６０００では、ジョブが開始された時点で、ジョブ受付部（２０００）からジョブ開始情報を受け取り、ジョブステップが終了した時点で、ジョブステップ終了情報とそのジョブステップでのファイルアクセス履歴情報をステップ終了受付部（４０００）から受け取る。さらに、ジョブが終了した時点で、ジョブ完了部（５０００）からジョブ終了情報を受け取る。こうしたジョブの実行履歴情報や、ファイルへのアクセス履歴情報を、収集した順に外部記憶装置（５００）に格納するのが、履歴情報収集部（６０００）である。
実行履歴解析部（７０００）は、６０００により収集された実行履歴（５００）を入力として、ファイルへのアクセス順序関係や、ファイルへの入出力の識別により、ジョブステップの実行開始をするための制約条件を求める。ジョブステップを実行するための制約は、参照するファイルが完成されていれば、直ちに実行することが可能であるため、ファイルへのアクセス順序関係のみを守れば、他には制約を受けずに実行することができる。８０００はジョブステップを実行するプログラム実行部である。
【０００８】
図２は、本発明で説明するＪＣＳの記述例である。図２を用いて、本実施例でのＪＣＳの記述規則を説明する。
まず。ＪＯＢは、一つの処理単位であるジョブを宣言する制御文である。本例で、ＪＯＢ１がジョブ名である。
このジョブでは、ＰＧＭ１というプログラムを実行した後、ＰＧＭ２を実行させ、その後にＰＧＭ３を実行する。このように、ジョブの中で実行すべきプログラムの指定と、プログラムの実行順序を宣言しているのがＳＴＥＰ文である。ＳＴＥＰ文で宣言したプログラムの実行単位がジョブステップである。すなわち、ジョブステップとは、ジョブを構成する実行の単位で、一つのプログラムの実行を意味する。
４１０では、ジョブステップ名がＳＴＥＰ１というジョブステップでＰＧＭ１というプログラムを実行する。そのジョブステップが完了した後に、ジョブステップ名がＳＴＥＰ２というジョブステップでＰＧＭ２というプログラムを実行する。さらに、ＳＴＥＰ２の実行が完了した後で、ジョブステップ名がＳＴＥＰ３というジョブステップでＰＧＭ３というプログラムを実行する。
各プログラムの実行中にファイルをアクセスする場合がある。このようにプログラムの実行中にアクセスするファイルを指定するのが、ＦＤ文である。ＦＤ文ではＦＩＬＥオペランドでアクセスするファイル名称を指定する。
このようにＪＣＳ中で定義したアクセスするファイルを、プログラムと対応づける必要がある。それがＦＤ名である。４１０の例では、ＩＮ１、ＯＵＴ１、ＩＮ２、ＯＵＴ２、ＩＮ３、ＯＵＴ３がＦＤ名である。また、ここで定義したファイルへのアクセスが入力なのか、出力なのかはプログラムの中で指定する。
【０００９】
次に、４１０の処理の流れを説明する。
まず、ＳＴＥＰ１ではＰＧＭ１というプログラムを実行する。ここでは、Ａ．ＤＡＴＡというファイルからデータを入力し、Ｂ．ＤＡＴＡというファイルへ実行結果を出力する。次に、ＳＴＥＰ２で、ＰＧＭ２というプログラムを実行する。ここでは、ＰＧＭ１の実行結果であるＢ．ＤＡＴＡというファイルのデータを入力し、実行結果をＣ．ＤＡＴＡというファイルへ出力する。ＳＴＥＰ２の実行終了後、ＳＴＥＰ３でＰＧＭ３というプログラムを実行する。ここでは、ＰＧＭ１の実行結果であるＢ．ＤＡＴＡというファイルのデータを入力し、実行結果をＤ．ＤＡＴＡというファイルへ出力する。
ここで、ＳＴＥＰ２とＳＴＥＰ３は、互いにＢ．ＤＡＴＡというファイルを参照するが、ＳＴＥＰ２でのＢ．ＤＡＴＡへのアクセスが入力と分かっている場合には、ＳＴＥＰ２とＳＴＥＰ３の間でデータの受け渡し関係がないため、並列に実行することが可能である。しかし、ＳＴＥＰ２でのＢ．ＤＡＴＡへのアクセスが入力と分かっていない場合には並列に実行することはできない。そこで、こうしたジョブステップの構成の場合に、ＳＴＥＰ１の実行が完了した後、ＳＴＥＰ２とＳＴＥＰ３の間にデータの受け渡し関係がない場合に、これらを並列に実行させることにより、処理時間の短縮を図ることが本発明の目的である。
【００１０】
図３を用いて、４１０のＳＴＥＰ２とＳＴＥＰ３を並列に実行させるための指定方法を説明する。これが、本実施例での記述規則とする。
４２０では、ＳＴＥＰ２とＳＴＥＰ３のＳＴＥＰ文にＥＸＥＣ＝ＳＴＥＰ１という指定が付加されている。これは、ＳＴＥＰ１というジョブステップが実行完了した時点で、実行開始可能であることを示す実行開始条件を宣言している。この宣言は事前にＪＣＳで行なえばよい。
本実施例では、上記の実行開始条件の宣言がＪＣＳで行なわれていない場合には、入力したＪＣＳに基づきＪＣＳ解析部１０００によりＳＴＥＰ文のオペランドに実行を開始できる条件である実行開始条件を付加することができるようにしている。
以上が、本実施例での構成およびジョブ制御文の記述規則である。
【００１１】
次に、第１の実施例について説明する。
図４は、ＪＣＳ解析部のフローチャートである。
まず、投入されたジョブのＪＣＳを全て読み込む（１００５）。
次に、ＪＣＳについて、ＥＸＥＣオペランドが指定されているＳＴＥＰ文があるかを調べる（１０１０）。
もしあれば、１０６０に分岐し、ジョブ受付部にＪＣＳを渡す。ない場合には、入力したＪＣＳを１行ずつ解析する。まず、解析の対象をＪＣＳの第１行目とする（１０１５）。
解析対象がＪＯＢ文であれば、１０５５に進み、解析対象を次の１行にする。ＪＯＢ文でなければ、１０２５に進み、ＳＴＥＰ文であるかを調べる。もし、ＳＴＥＰ文であれば１０３０に進み、ＳＴＥＰ文のアドレス（ＳＴＥＰ文の格納されているアドレス）を記憶し、１０５５へ進む。ＳＴＥＰ文でなければ、残った指定は、アクセスするファイルを指定したＦＤ文となる。
そこで、１０３５では、このＦＤ文と等しいファイル名を指定したＦＤ文を、前段ジョブステップから上段のジョブステップ向かってサーチする。最初に見つかった時点で、１０４５に進み、見つからなかったら１０５５に分岐して解析対象を次の１行目にする（１０４０）。
１０４５では、１０３０で記憶しているＳＴＥＰ文に対して、ＥＸＥＣオペランドを付加し、１０３５で検索した、同一のファイル名を示すＦＤ文を指定したジョブステップ名を指定する。
次に、１０５０では入力した全てのＪＣＳについて上記解析を行ったかをチェックし、解析した場合には、１０６０に進み、ジョブ受付部にＪＣＳを渡す。検索していない場合には、１０５５に進み、解析の対象を次の１行として、上記解析を繰り返す。
【００１２】
次に、ジョブ受付部（２０００）の処理について、図５を用いて説明する。図５はジョブ実行受付部のフローチャートである。
まず、２００５でＪＣＳ解析部からＪＣＳを受け取る。
次に２０１０でジョブステップの並列度を求める。これは、入力したＪＣＳのＥＸＥＣオペランドの実行開始条件の指定が等しいか、ＥＸＥＣオペランドに実行開始条件の指定がないＳＴＥＰ文数の最大値である（ＥＸＥＣオペランドの指定がないＳＴＥＰは並列処理可能である）。
次に、実行履歴情報であるジョブ開始レコードを作成し、履歴情報収集部に渡す（２０１５）。最後に、ジョブ実行状況を監視するためのＪＣＳテーブルを作成し、実行管理マスタテーブルからポイントされる実行待ちＪＣＳテーブルキューの最終エントリに繋げる。ここで、ジョブ開始レコードや、ＪＣＳテーブル、実行管理マスタテーブルの詳細は、後で説明することにする。
【００１３】
図６は、ジョブ受付部（２０００）や、ジョブステップ実行処理部（３０００）、ステップ終了受付部（４０００）およびジョブ完了部（５０００）で使用するテーブルの構造である。
実行管理マスタテーブル（３１００）はジョブ実行状況の監視や、ジョブを実行させることができる空間を管理するマスタテーブルである。
実行空間管理テーブル（３２００）は、現在、実行しているジョブを記すテーブルであり、実行中の場合は、対応するジョブのＪＣＳテーブル（３３００）からポイントされるキューに繋がり、実行待ちの場合は、実行管理マスタテーブル（３１００）の３１１０と３１２０によってポイントされる空き実行空間管理テーブルキューにつながる。
ＪＣＳテーブルは、各ジョブのＪＣＳの内容や、使用している空間に対応する実行空間管理テーブル（３２００）を管理するためのテーブルである。
ジョブの実行中は、３１３０と３１４０によりポイントされる実行中のＪＣＳテーブルキューに繋がり、実行待ちの場合は、３１５０３１６０によりポイントされる実行待ちのＪＣＳキューにつながる。このＪＣＳテーブル（３３００）と実行空間管理テーブル（３２００）をプログラム実行部に渡すことにより、一つのジョブステップが実行空間管理テーブル（３２００）に対応する空間上で実行されることとなる。
【００１４】
図７は、実行空間管理テーブルの詳細である。
３２１０と３２２０は、実行管理マスタテーブル（３１００）やＪＣＳテーブル（３２００）によって管理されるキューを生成するためのポインタである。３２３０は実行させるジョブ名を格納する領域であり、３２４０はジョブステップ名を格納する領域である。３２５０は実行状態を示すフラグで、実行中はＯＮとなり、実行していないときはＯＦＦとなる。３２６０は対応するアドレス空間の番号である。
図８はＪＣＳテーブル（３３００）の構造である。ＪＣＳテーブルはジョブ対応に作成されるテーブルである。
３３１０と３３２０は実行管理マスタテーブルによって管理されるＪＣＳテーブルキューを生成するためのポインタである。
３３３０と３３４０は、ジョブステップを実行させるために確保した実行空間管理テーブルのキューを管理するためのポインタである。
３３５０はジョブステップの完了マスクである。上段のジョブステップから、左詰めに２ビットずつ割当てる。この２ビットが、’００’の時は未実行を意味し、’１０’は実行中を意味する。さらに、実行が完了すると’１１’となる。
３３６０は、ジョブステップ数の格納領域である。３３７０はジョブ受付部の２０１０で求めた並列度を格納する領域である。３３８０はＪＣＳの内容を格納する領域である。
【００１５】
図９を用いて、ジョブステップ実行処理部のフローを説明する。まず、空き実行空間管理テーブルキューのエントリ数を３０１０で求める。
次に、３０２０で実行待ちＪＣＳキューの先頭から、３０１０で求めたエントリ数よりも並列度（３３７０）が小さいＪＣＳテーブルを検索する。もしなかったら、３０３０で３０１０にもどる。この場合、一定時間間隔待って３０１０に戻ってもよい。
３０３０で有ると分かった場合には、３０４０でＪＣＳテーブル内の並列度分の実行空間管理テーブルを空きキューから切離し、３１１０と３１２０を更新する。３０２０で求めたＪＣＳテーブルで管理する実行空間管理テーブルキューに接続する。このキューの管理に３３３０と３３４０を使用する。３０４０は、ステップ終了受付部よりコールされた時の入口点でもある。
つぎに、３０５０でＪＣＳの内容（３３８０）から、上段のＳＴＥＰ文から解析を進め、実行できるジョブステップを検索する。この検索条件は、
（１）ＳＴＥＰ文にＥＸＥＣオペランドの指定がないジョブステップで、まだ未実行であるジョブステップであること
もしくは、
（２）ＳＴＥＰ文のＥＸＥＣオペランドで指定されたジョブステップがすでに実行を完了しているジョブステップであること
である。ここで、ジョブステップの実行状況は、ジョブステップマスク（３３５０）の各ジョブステップに対応するフィールドを参照することで確認できる。
３０６０では、実行可能なジョブ名とジョブステップ名を各々３２３０と３２４０に格納し、実行フラグ（３２５０）をＯＮにする。
３０７０では、登録したジョブステップ名の対応するジョブステップ完了マスク（３３５０）の対応するフィールドを’１０’として実行中にし、更新した実行空間管理テーブル（３２００）とＪＣＳテーブル（３３００）とをプログラム実行部（８０００）に渡す。
プログラム実行部では、実行空間管理テーブルに記された空間番号（３２６０）上でジョブステップを実行させる。
【００１６】
次に図１０を用いて、ステップ終了受付部を説明する。
ジョブステップが終了すると、プログラム実行部（８０００）から通知をうける。
まず、４０１０で実行完了の通知をうけたジョブステップに対応するジョブステップ完了マスク（３３５０）のフィールドを’１１’とする。
４０２０では、実行を完了した実行空間管理テーブル（３２００）のジョブ名（３２３０）、ジョブステップ名（３２４０）をクリアし、実行フラグ（３２５０）をＯＦＦにする。
次に、４０３０では、実行履歴として、ジョブステップ終了レコードを作成し、履歴情報収集部（６０００）に渡す。
次に、４０４０ではジョブステップ完了マスク（３３５０）を左から２ビットずつジョブステップ数（３３６０）回見て、’００’となっているフィールドがあるかをチェックする。ある場合には、まだ実行を開始していないジョブステップが存在することを意味するので、４０７０に進み、ジョブステップ実行処理部をコールする（図９のステップ３０４０に進む）。
もし、存在しない場合は、４０５０でジョブステップ完了マスク（３３５０）を左から２ビットずつジョブステップ数（３３６０）回見て、’１０’となっているフィールドがあるかをチェックする。もし、存在すれば、まだ実行中のジョブステップが存在することを意味する。そこで、’１０’というフィールドがなくなるまで、４０５０の実行を繰り返す。４０５０で’１０’となっているフィールドがなくなると、すべてのジョブステップの実行を終了したことを意味するので、４０６０でジョブ完了部に制御を渡す。
【００１７】
最後に、図１１を用いて、ジョブ完了部（５０００）のフローを示す。
まず、５０１０で実行履歴として、ジョブ終了レコードを作成し、履歴情報収集部（６０００）に渡す。
次に、５０２０で、ＪＣＳテーブル（３３００）に管理されている実行空間管理テーブル（３２００）を実行管理マスタテーブル（３１００）の３１１０と３１２０によって管理される空きキューにつなぐ。
最後にＪＣＳテーブルを解放する。
【００１８】
次に、第２の実施例を説明する。
第２の実施例は、過去のジョブの実行履歴情報とファイルへのアクセス履歴情報をもとにジョブステップの並列実行を解析し、その結果を使って、ジョブステップを並列実行させるものである。
バッチ処理には、データを１日単位や、１週間単位、１ヵ月単位などにまとめておいて、一括して処理するバッチ処理があり、このような処理では、１日、１週間などの間をおいて同一ジョブを実行することになり、このような場合に第２の実施例は有効である。
第１の実施例では、ＪＣＳ解析部で実行開始条件を求める場合には、ファイルアクセスが入力か出力かはプログラムの中で指定しているため、ファイルアクセスが入力か出力かを識別できない。したがって、図２に示すＪＣＳを投入すると、ＳＴＥＰ２のＥＸＥＣオペランドは、ＥＸＥＣ＝ＳＴＥＰ１となり、ＳＴＥＰ３のＥＸＥＣオペランドは、ＥＸＥＣ＝ＳＴＥＰ２となり、結局逐次的にジョブステップを実行させることとなってしまう。
ここに示す第２の実施例を用いると、ＳＴＥＰ３のＥＸＥＣオペランドはＥＸＥＣ＝ＳＴＥＰ１となり、ＳＴＥＰ１の実行完了後に、ＳＴＥＰ２とＳＴＥＰ３をパラレルに実行させることができる。
第２の実施例が第１の実施例と異なる点は、実行履歴解析部（７０００）が加わる点と、ＪＣＳ解析部（１０００）のフローが異なる点である。
【００１９】
本実施例の説明は、まずジョブの実行履歴レコードとファイルアクセス履歴レコードの詳細を説明し、次に、その履歴情報を用いる実行履歴解析部のフローを説明する。最後に、ＪＣＳ解析部のフローを説明する。
図１２、図１３、図１４および図１５を用いて履歴情報について説明する。
ジョブの実行が開始されると、ジョブ受付部（２０００）がジョブ開始情報（５１０）を出力し、ジョブの実行が終了すると、ジョブ完了部（５０００）がジョブ終了情報（５２０）を出力する。
さらに、ジョブ実行中に、ジョブステップが終了すると、ステップ終了受付部（４０００）がジョブステップ終了情報（５３０）を出力する。
各ジョブステップで実行しているプログラムが、アクセス終了を宣言する命令（ＣＬＯＳＥ命令）を発行すると、ＣＬＯＳＥしたファイルに関して、ファイルアクセス履歴情報（５４０）を出力する。
上記各レコードを、情報の種類を区別するために、レコードの中に識別子を持っている。ジョブ開始情報（５１０）はＸ’０１’（５１１）であり、ジョブ終了情報（５２０）はＸ’０２’（５２１）、さらにジョブステップ情報（５３０）は、Ｘ’０３’である。ファイルアクセス履歴情報（５４０）に関しては、プログラムがファイルのデータを入力したのか、出力したのかによって異なる。識別子（５４１）は、入力の場合がＸ’０４’で、出力の場合がＸ’０５’である。
上記各情報は、イベントが発生する度に時系列に履歴情報収集部（６０００）に渡され、履歴情報収集部（６０００）は外部記憶装置（５００）に出力する。
【００２０】
以下に、上記各情報の出力レコード形式を説明する。
図１２は、ジョブ開始情報のレコード形式である。
当該レコードは、ジョブの実行が開始された時点で、ジョブ受付部（２０００）によって出力される。５１１は識別子で、当該レコードはＸ’０１’である。５１２はジョブ名である。５１３はジョブ開始時刻である。
図１３は、ジョブ終了情報のレコード形式である。
５２１は識別子で、当該レコードはＸ’０２’である。５２２はジョブ名である。５２３はジョブ実行の開始時刻を示し、５２４はジョブ実行の終了時刻を示す。
図１４は、ジョブステップ終了情報のレコード形式である。
５３１は識別子で、当該レコードではＸ’０３’である。５３２は終了したジョブステップが属しているジョブの名称である。５３３は終了したジョブステップが属しているジョブの開始時刻である。５３４はジョブステップ名である。５３５はジョブステップの開始時刻であり、５３６はジョブステップの終了時刻である。
図１５は、ファイルアクセル履歴情報のレコード形式である。
当該レコードは、プログラムがＣＬＯＳＥ命令を発行した時に出力される。５４１は識別子である。ただし、プログラムがファイルからデータを入力した場合と出力した場合とで、識別子（５４１）の内容が異なる。入力の場合はＸ’０４’であり、出力の場合はＸ’０５’である。
５４２は、ファイルアクセスをしたプログラムが属するジョブのジョブ名である。５４３は、ジョブの開始時刻である。５４４はファイルアクセスをしたプログラムが実行したジョブステップのジョブステップ名である。５４５はジョブステップの開始時刻である。５４６はＦＤ名である。５４７はファイルの識別子であるファイル名である。
【００２１】
実行解析部（７０００）では、上記履歴情報を用いて、各ジョブステップの実行開始条件を求める。
図１６に、実行履歴解析部（７０００）の構成を示す。
実行履歴解析部（７０００）は、履歴情報入力（７１００）と実行条件解析（７２００）に分かれる。履歴情報入力（７１００）では、上記履歴情報を入力し、ジョブとジョブステップ、およびジョブステップとアクセスしたファイルを関連づける。実行条件解析（７２００）では、履歴情報入力（７１００）によって関連づけられた結果から、各ジョブステップに関して、実行開始条件を求める。
【００２２】
図１７から図２２に、実行履歴解析部で使用するテーブルの関連および、各テーブルの詳細を示す。
図１７は、実行条件解析（７２００）が、入力した履歴情報を格納し、解析するために用意するテーブル群のテーブル関連図である。各テーブルの詳細は、図１８から図２２に示す。
履歴マスタテーブル（ＭＳＴＨ）（７５００）は、実行履歴解析部（７０００）のマスタテーブルであり、ジョブの実行履歴を格納するＪＯＢＨ（７６００）キューの管理と、各ジョブステップの実行開始条件を格納する実行条件テーブル（７９００）を管理する。
ジョブ実行履歴テーブル（ＪＯＢＨ）（７６００）は、ジョブ単位に作成され、ジョブ開始情報（５１０）やジョブ終了情報（５２０）を格納する。また、ＪＯＢＨ（７６００）キューは、ジョブの実行順序にしたがっている。さらに、ジョブ内で実行されたジョブステップ情報を格納するジョブステップ実行履歴テーブル（ＳＴＰＨ）（７７００）キューの管理をする。
ＳＴＰＨ（７７００）は、ジョブステップ単位に作成され、同一ジョブ内で実行された順にキューになってならんでいる。ＳＴＰＨ（７７００）は、ジョブステップの開始情報や終了情報を格納している。さらにＳＴＰＨ（７７００）は、ジョブステップ内でアクセスしたファイル情報を格納するファイルアクセス履歴テーブルＦＤＨ（７８００）キューの管理をする。
ＦＤＨ（７８００）は、プログラムがアクセスしたファイル単位に作成され、アクセス先のファイル情報を格納する。また、ＦＤＨ（７８００）は、プログラムが実行したジョブステップごとに、キューを作成する。
実行条件テーブル（ＥＸＣＮ）（７９００）は、履歴情報に格納されている全てのジョブステップについて、実行開始が可能な条件を格納している。
【００２３】
図１８から図２２に、上記で説明したテーブルの詳細を記す。
図１８は、履歴マスタテーブル（ＭＳＴＨ）（７６００）のテーブル構造である。
ＭＳＴＨは、ＪＯＢＨキューとＥＸＣＮキューの管理をするマスタテーブルである。ＭＳＴＨ（７５００）は、先頭ＪＯＢＨアドレス（７５１０）、最終ＪＯＢＨアドレス（７５２０）、ＥＸＣＮアドレス格納域（７５３０）を格納する。
図１９は、ＪＯＢＨ（７６００）のテーブル構造である。
ＪＯＢＨは、ジョブ開始情報（５１０）を入力した時に作成される。７６１０は次ＪＯＢＨアドレス格納域であり、７６２０は前ＪＯＢＨアドレス格納域である。７６１０と７６２０を使用して、キューを形成する。７６３０は先頭ＳＴＰＨアドレス格納域であり、７６４０は最終ＳＴＰＨアドレス格納域である。７６３０と７６４０は、ＪＯＢＨに対応するジョブの中で実行されたジョブステップ情報を格納するＳＴＰＨのキューを管理するものである。
７６５０はジョブ開始時刻の格納域であり、７６６０はジョブの終了時刻の格納域である。また、７６７０はジョブ名の格納域である。７６５０と７６７０は、ジョブ開始情報レコード（５１０）よりコピーされる。７６６０はジョブ終了情報レコード（５２０）からコピーされる。
【００２４】
図２０は、ＳＴＰＨ（７７００）のテーブル構造である。
ＳＴＰＨ（７８００）は、ファイルアクセス履歴情報（５４０）を入力した時に、当該ファイルに対してアクセスしたプログラムが属しているＳＴＰＨ（７７００）が用意されていない場合に作成する。
７７１０は次ＳＴＰＨテーブルアドレス格納域であり、７７２０は前ＳＴＰＨテーブルアドレスの格納域である。７７１０と７７２０により、ジョブ単位に実行されたジョブステップを管理するＳＴＰＨキューが形成される。７７３０は先頭ＦＤＨアドレス格納域であり、７７４０は最終ＦＤＨアドレス格納域である。７７３０と７７４０は、ジョブステップ内でアクセスしたファイル情報を格納するＦＤＨキューを管理する。７７５０はジョブステップ名の格納域である。７７６０はジョブステップの開始時刻格納域で、７７７０はジョブステップ終了時刻格納粋である。
図２１は、ＦＤＨ（７８００）のテーブル構造である。
ＦＤＨ（７８００）は、ファイルアクセス履歴情報（５４０）を入力した時に作成する。ＦＤＨ（７８００）は、ファイルへアクセスしたプログラムが実行されたジョブステップ単位で管理される。７８１０は次ＦＤＨアドレス格納域であり、７８２０は前ＦＤＨアドレス格納域である。７８１０と７８２０を用いて、ＦＤＨキューを作成する。７８３０は、ＪＣＳで記述したＦＤ名の格納域である。同様に、７８４０はファイル名の格納域である。また、７８５０は入出力識別子の格納域である。
図２２は、実行条件テーブル（ＥＸＣＮ）（７９００）のテーブル構造である。
７９１０にはジョブ名が記され、７９２０にはそのジョブの中で実行されるジョブステップ名が記される。さらに、７９３０には、実行を開始するための条件、すなわち、当該ジョブステップを開始するために終了しなければならないジョブステップ名が格納される。
【００２５】
図２３は、履歴情報入力（７１００）のフローである。
まず、履歴情報レコードを１レコード入力する（７１０５）。７１１０では、入力したレコードがジョブ開始情報レコード（５１０）であるか否かをチェックする。すなわち、識別子（５１１）がＸ’０１’であるか否かをチェックする。識別子（５１１）がＸ’０１’である場合には、７１１５へ進み、ＪＯＢＨ（７６００）を作成する。ここで、ＪＯＢＨ（７６００）に対し、ジョブ開始時刻（７６５０）と、ジョブ名（７６７０）を登録する。作成したＪＯＢＨは、７５１０と７５２０によって管理されるＪＯＢキューに登録する。
７１１０で識別子がＸ’０１’でない場合、７１２０に進む。７１２０では、入力したレコードがファイルアクセス履歴情報レコード（５４０）であるか否かをチェックする。すなわち、入力したレコードの識別子（５４１）が、Ｘ’０４’もしくはＸ’０５’であるか否かをチェックする。入力したレコードが、上記条件を満たす場合は７１２５へ進み、上記条件を満たさない場合は７１３５へ進む。
７１２５では、まず、７５１０および７５２０に管理されるＪＯＢＨ（７６００）キューをたどって、下記の条件を満たすＪＯＢＨ（７６００）を検索する。
（１）入力レコードのジョブ名（５４２）とＪＯＢＨ（７６００）のジョブ名（７６７０）が等しい。
（２）入力レコードのジョブ開始時刻（５４３）と、ＪＯＢＨ（７６００）
ジョブ開始時刻（７６５０）が等しい。
（３）ジョブ終了時刻（５３６）が未登録である。
当該ＪＯＢＨ検索処理において、入力レコードに記したファイルへアクセスしたプログラムが属するジョブの開始情報レコード（５１０）は、すでにシステムに出力されており、当該ＪＯＢＨ検索処理では、必ずＪＯＢＨキューに上記３条件を満たすＪＯＢＨ（７６００）が存在する。
次に、上記ＪＯＢＨ検索処理により求められたＪＯＢＨ（７６００）が管理するＳＴＰＨ（７７００）キューから、下記の３条件を満たすＳＴＰＨ（７７００）を検索する。
（１）入力レコードのジョブステップ名（５４４）とＳＴＰＨ（７７００）のジョブステップ名（７７５０）が等しい。
（２）入力レコードのジョブステップ開始時刻（５４５）と、ＳＴＰＨ（７７００）のジョブステップ開始時刻（７７６０）が等しい。
（３）ジョブステップ終了日付と終了時刻（７７００）が未登録である。
当該ＳＴＰＨの検索処理で、当該３条件を満足するＳＴＰＨを検索できなかった場合、新たにＳＴＰＨ領域を確保し、入力レコードの中から、ジョブステップ名（５４２）とジョブステップ開始時刻（５４４）をコピーする。以後、本ステップでの操作対象とするＳＴＰＨを当該ＳＴＰＨとし、７１３０に進む。
上記ＳＴＰＨの検索処理で、上記３条件を満足するＳＴＰＨ（７７７０）を検索できた場合は、検索したＳＴＰＨ（７７００）を操作対象として、７１３０に進む。
７１３０では、まず、ＦＤＨ領域を確保する。確保したＦＤＨ（７８００）に対して、入力レコード情報から、ＦＤ名（５４６）、ファイル名（５４７）、入出力識別子（５４８）を登録する。ここで、入出力識別子（７８６０）には、ファイルアクセス履歴情報レコード（５４０）の識別子（５４８）をコピーする。登録処理をしたＦＤＨは、上記ＳＴＰＨ検索処理で操作対象となったＳＴＰＨ（７７００）が管理するＦＤＨキューの最後尾に接続する。
【００２６】
７１３５では、入力レコードがジョブステップ終了情報レコードか否かをチェックする。すなわち、入力レコードの識別子がＸ’０３’か否かをチェックする。
入力レコードの識別子がＸ’０３’の場合は、７１４０へ進む。７１４０では、ＭＳＴＨ（７５００）が管理するＪＯＢＨキューの中から、下記の３条件を満たすＪＯＢＨ（７６００）を検索する。
（１）入力レコードのジョブ名（５３２）とＪＯＢＨのジョブ名（７６７０）が等しい。
（２）入力レコードのジョブ開始時刻（５３２）と、ＪＯＢＨのジョブ開始時刻（７６５０）が等しい。
（３）ＪＯＢＨ（７６００）のジョブ終了時刻（７６６０）が未登録である。
当該ＪＯＢＨ検索処理において、入力レコードに記したジョブステップが属するジョブの開始情報レコード（５１０）は、すでに出力されており、当該ジョブ開始情報レコード（５１０）に対応するＪＯＢＨ（７６００）を作成済みである。
次に検索したＪＯＢＨ（７６００）が管理するＳＴＰＨ（７７００）キューにおいて、下記３条件を満たすＳＴＰＨ（７７００）を検索する。
（１）入力したレコードのジョブステップ名（５３４）とＳＴＰＨ（７７００）のジョブステップ名（７７５０）が等しい。
（２）入力レコードのジョブステップ開始時刻（５３５）と、ＳＴＰＨ（７７００）のジョブステップ開始時刻（７７６０）が等しい。
（３）ＳＴＰＨ（７７００）のジョブステップ終了時刻（７７７０）が未登録である。
当該ＳＴＰＨ（７７００）の検索処理において、上記３条件を満たすＳＴＰＨを検索できた場合は、入力レコードの中より、ジョブステップ終了時刻（５３６）をＳＴＰＨ（７７００）に登録する。
【００２７】
上記ＳＴＰＨ検索処理で、条件を満たすＳＴＰＨ（７７００）を検索できなかった場合、新しくＳＴＰＨ領域を確保し、入力レコードの情報をもとに、５３４から５３６の領域に対応する情報をコピーする。次に、上記ＪＯＢＨ（７７００）により、検索したＪＯＢＨによって管理されるＳＴＰＨキューの最後尾に当該ＳＴＰＨを接続する。
７１３５において、入力レコードの識別子がＸ’０３’でなかった場合、７１４５に進む。７１４５では、入力レコードがジョブ終了情報レコードであるか否かをチェックする。すなわち、入力レコードの識別子がＸ’０２’であるか否かをチェックする。入力レコードの識別子がＸ’０２’である場合は、７１５０へ進む。７１５０では、まず、下記３条件を満たすＪＯＢＨ（７５００）を検索する。
（１）入力レコードのジョブ名（５２２）とＪＯＢＨのジョブ名（７６７０）が等しい。
（２）入力レコードのジョブ開始時刻（５２３）と、ＪＯＢＨ（７６００）のジョブ開始時刻（７６５０）が等しい。
（３）ＪＯＢＨ（７６００）のジョブ終了了時刻（７６６０）が未登録である。
当該ＪＯＢＨ検索処理において、入力レコードに記したジョブ終了情報に対応するジョブ開始情報レコード（５１０）は出力されており、ＯＳ適用ジョブ検索手段（１３００）は、当該ジョブ開始情報レコード（３００）に対応するＪＯＢＨを作成済みである。従って、当該ＪＯＢＨ検索処理では、必ず上記３条件を満たすＪＯＢＨが存在する。
次に、上記ＪＯＢＨ検索処理で求めたＪＯＢＨに対して、入力レコードより、ジョブ終了時刻（５２４）を登録する。
【００２８】
７１４５において、入力レコードがジョブ終了情報レコードでなかった場合は、７１５５へ進む。同様に、７１３０、７１４０、および７１５０での処理を完了した後も、７１５５へ進む。７１５５では、今回入力したレコードが、最終レコードか否かをチェックする。最終レコードの場合は、当該システム稼働情報の入力処理を完了する。最終レコードでない場合は、７１０５へ進み、次レコードを入力して、同様の処理をする。
これにより、ジョブとジョブステップの関係、およびジョブステップとアクセスしたファイルとの関係を関係づけることができた。これを用いて、各ジョブステップの実行開始条件を求め、ＥＸＣＮ（７９００）を作成する。
【００２９】
図２４を用いて、実行条件解析のフローを説明する。
まず、解析の対象をＪＯＢＨキューの先頭エントリとする（７２０５）。まず、これで、解析するジョブを選定する。
次に、解析対象となったジョブに属するジョブステップがアクセスしたファイルを逐一調べることにより、ジョブステップの実行開始条件を定めていく。そこで、７２１０では、解析対象を最終ジョブステップに定めるために、解析対象のＪＯＢＨが管理するＳＴＰＨキューの中の最終エントリを解析の対象とする。
７２１５では、解析対象となったＳＴＰＨが先頭エントリか否かを調べ、もし先頭エントリであれば、７２５０へ進む。それ以外は、７２２０へ進む。
７２２０では、解析対象となったＳＴＰＨが管理するＦＤＨの中から、入出力識別子が入力であるＦＤＨをサーチする。これは、複数でもかまわない。７２２５で判断した結果、ある場合には７２３０に進み、ない場合には７２４５へ進む。
７２３０では、現在解析対象となっているＳＴＰＨの前段から上段のＳＴＰＨに向かって、サーチしたＦＤＨとファイル名が同一で、入出力識別子が出力であるＦＤＨをサーチする。もしある場合には７２４０へ進み、ない場合には７２４５へ進む。
７２３０および７２３５の検索の結果、上記条件を満たすＳＴＰＨが存在する場合には、解析対象としたＳＴＰＨに対応するジョブステップは、７２３０でサーチしたＳＴＰＨに対応するジョブステップが終了しないかぎり、実行を開始することができない。そこで、７２４０では、ＥＸＣＮ（７９００）に解析対象となったジョブ名、ジョブステップ名、および、７２３０でサーチしたジョブステップ名を登録する。
７２４５では、次のジョブステップの実行条件を調べるために、前段のＳＴＰＨを解析対象として、７２１５へ戻る。
７２１５から分岐した７２５０では、次のジョブを解析対象とする前に、現在解析対象となっているＪＯＢＨが、ＪＯＢＨキューの最終エントリかを調べ、最終エントリの場合は処理を終了する。最終エントリでない場合には、７２５５へ進み、次ＪＯＢＨを解析対象として、７２１０へ戻る。
実行履歴解析部（７０００）により得られたＥＸＣＮ（７９００）をもとに、ＪＣＳ解析部では、ジョブステップの実行条件を入力したＪＣＳに付加して、ジョブ受付部に渡す。
【００３０】
第２５図を用いて、ＪＣＳ解析部のフローを説明する。
まず、１ジョブ文のＪＣＳを１０００５で読み込む。１００１０では、ＥＸＣＮ（７９００）から入力したＪＣＳとジョブ名が等しいエントリをサーチする。
もし、存在しない場合は、１００１５から１００５５へ分岐し、ジョブ受付部（２０００）にＪＣＳを渡す。
存在する場合には、１００２０へ進み、１００１０でサーチしたエントリを解析の対象に絞る。１００２５ではＪＣＳ中の２番目のＳＴＥＰ文を解析の対象にする。
１００３０では、解析対象となったＥＸＣＮのエントリから、ＳＴＥＰ文に示されたジョブステップ名と等しいエントリをサーチする。
存在する場合には１００４０へ進み、存在しない場合は１００４５へ進む（１００３５）。
１００４０では、ＳＴＥＰ文にＥＸＥＣオペランドを付加し、サーチしたＥＸＣＮの実行条件をＥＸＥＣオペランドのパラメタに指定する。
１００４５では全てのＳＴＥＰ文について上記の検索を行ったかをチックし、検索した場合は１００５５へ進む。まだ全てのＳＴＥＰ文を解析していない場合には、１００５０へ進み、次のＳＴＥＰ文を解析の対象にして、１００３０へ戻る。
【００３１】
【発明の効果】
本発明によれば、複数のジョブステップから構成されるジョブにおいて、ファイルの受け渡し関係のないジョブステップを並列実行させることを可能とする事で、ジョブの実行時間を短縮することができる。
【図面の簡単な説明】
【図１】本発明の構成を示す機能ブロック図である。
【図２】ジョブ制御文の例を示す図である。
【図３】本発明を使用する場合におけるジョブ制御文の１例を示す図である。
【図４】第１の実施例におけるＪＣＳ解析部のフローチャートを示す図である。
【図５】ジョブ受付部のフローチャートを示す図である。
【図６】ジョブ受付部、ジョブステップ実行処理部、ステップ終了受付部、およびジョブ完了部で使用するテーブルのテーブル関連を示す図である。
【図７】実行空間管理テーブルのテーブル構造を示す図である。
【図８】ＪＣＳテーブルのテーブル構造を示す図である。
【図９】ジョブステップ実行処理部のフローチャートを示す図である。
【図１０】ステップ終了受付部のフローチャートを示す図である。
【図１１】ジョブ完了部のフローチャートを示す図である。
【図１２】第２の実施例で参照するジョブ開始情報レコードの構造を示す図である。
【図１３】ジョブ終了情報レコードの構造を示す図である。
【図１４】ジョブステップ終了情報レコードの構造を示す図である。
【図１５】ファイルアクセス履歴情報レコードの構造を示す図である。
【図１６】第２の実施例における実行履歴解析部のフローチャートを示す図である。
【図１７】実行履歴解析部で使用するテーブルの関連を示す図である。
【図１８】履歴マスタテーブルの構造を示す図である。
【図１９】ジョブ実行履歴テーブルの構造を示す図である。
【図２０】ジョブステップ実行履歴テーブルの構造を示す図である。
【図２１】ファイルアクセス履歴テーブルの構造を示す図である。
【図２２】実行条件テーブルの構造を示す図である。
【図２３】第２の実施例における履歴情報入力のフローチャートを示す図である。
【図２４】第２の実施例における実行条件解析のフローチャートを示す図である。
【図２５】第２の実施例におけるＪＣＳ解析部のフローチャートを示す図である。
【符号の説明】
１００計算機システム
２００中央処理装置
３００メモリ
４００ジョブ制御文を格納する外部記憶装置
５００実行履歴を格納する外部記憶装置
５１０ジョブ開始情報レコード
５２０ジョブ終了情報レコード
５３０ジョブステップ終了情報レコード
５４０ファイルアクセス履歴情報レコード
１０００ＪＣＳ解析部
２０００ジョブ受付部
３０００ジョブステップ実行処理部
３１００実行管理マスタテーブル
３２００実行空間管理テーブル
３３００ＪＣＳテーブル
４０００ステップ終了受付部
５０００ジョブ完了部
６０００履歴情報収集部
７０００実行履歴解析部
７５００履歴マスタテーブル
７６００ジョブ実行履歴テーブル
７７００ジョブステップ実行履歴テーブル
７８００ファイルアクセス履歴テーブル
７９００実行条件テーブル[0001]
[Industrial applications]
The present invention relates to a job scheduling method for a computer system, and particularly to a job execution control method.
[0002]
[Prior art]
One of the usage forms of the computer is a batch process in which collected data such as sales information and inventory information is collected in units of one day, one week, one month, and the like, and is collectively counted. The batch totaling process is a system that obtains a final execution result by executing some processing programs.
A logical unit of work for obtaining such an execution result is called a job. In one job, a plurality of processing programs are executed, and an execution result is obtained. An execution unit of one program is called a job step.
The programs to be executed in such a batch process and the files accessed by the programs are written in the job control language (JCL). Described Defined by job control statement (JCS).
In general, the lower job step refers to the execution result of the upper job step, and the lower job step refers to the execution result of the lower job step to repeat the process of performing the final execution. Get results.
As described above, the method of executing a job including a plurality of job steps is described in ANDREW S.A. As described in TANENBAUM, "MODERN OPERATING SYSTEMS" (Prentice-Hall International Editions, pages 6 to 7), generally, a method of sequentially executing the job steps one by one from the upper job step is generally used. In this case, one address space is allocated for execution of each job, and job steps are executed one by one on that space. As a result, in an operating system that generates and manages multiple address spaces, a plurality of jobs can be executed in parallel, and the processing time of the entire batch process can be reduced.
[0003]
[Problems to be solved by the invention]
2. Description of the Related Art In recent years, with the progress of semiconductor technology and the like, the processing capabilities of a central processing unit (CPU) and an input / output device for performing data calculation and the like have been remarkably advanced. Further, in the CPU, a distributed environment for improving the throughput of the program by arranging a large number of CPUs, distributing the execution of the program to each CPU, and improving the degree of parallelism of the processing is intended.
However, the above conventional technique has a problem that job steps cannot be processed in parallel in the execution schedule of the job steps.
Here, a job including three job steps of job step 1, job step 2, and job step 3 will be described as an example. The job processing configuration is such that the job step 3 refers to the execution results of the job steps 1 and 2. In the prior art, the job steps are executed one by one in the order of job step 1, job step 2, and job step 3. However, job step 1 and job step 2 can be executed in parallel because there is no data transfer relationship.
An object of the present invention is to reduce batch processing time by executing job steps that can be executed in parallel in one job.
[0004]
[Means for Solving the Problems]
In order to achieve the above object, in the present invention,
A computer system that specifies a program to be executed using a job control statement (JCS) and a resource used by the program, accesses a file, and executes a plurality of jobs including a plurality of job steps in parallel or sequentially. At
For each job step, a parameter specifying an execution start condition, which is a condition under which execution can be started, is provided in the JCS. When a job is submitted, the JCS defining the job is input, and all job steps of the job are input. Obtaining the maximum value of the total number of job steps that can be executed in parallel (maximum degree of parallelism) by obtaining the maximum value of the sum of the number of job steps having the same content as the parameter and the number of job steps without the specification
Securing resources for the programs of the maximum degree of parallelism to be executed in parallel;
Allowing execution of a job step satisfying an execution start condition in the job;
The method further includes monitoring the execution status of all the job steps, and releasing the secured resources when all the job steps have completed execution.
In addition, in order to obtain from the JCS a parameter specifying an execution start condition, which is a condition under which the execution of each of the above job steps can be started,
When a job is submitted, a JCS defining the job is input, and a pair of job steps accessing the same file is obtained by referring to a file identifier accessed by each job step defined in the JCS. ,
In the paired job steps, the execution order of the job step defined by the JCS, which is later in execution order, is defined as after completion of execution of the other paired job step as the execution start condition. Determining an execution start condition;
A step of writing the determined execution start condition as a parameter in the input JCS is provided.
In addition, in order to obtain, from the job execution history, a parameter that specifies an execution start condition that is a condition under which execution of each of the above job steps can be started,
At the time of execution of the job, the job identifier, the job step identifier, the start time of the job step, the accessed all file identifiers, and whether or not the accessed all the accessed files were output, Collecting history information including an access type indicating whether or not there has been;
In the same job, the start time of a job step in which the file identifiers are equal, the access type is output and input, and the access type is output is the start time of a job step in which the access type is input Determining a pair of job steps preceding the time;
Determining an execution start condition that defines an execution start condition of the job step whose input is the access type as immediately after completion of the job step whose output is the access type, and saving;
When the same job as the job is re-submitted, a step of writing the stored execution start condition as a parameter into the input JCS is provided.
[0005]
[Action]
The JCS analysis unit extracts a parallel execution designation unit of the job step specified in the JCS, or extracts a parallel execution executable unit based on file information accessed in each job step defined in the JCS, or executes the job. By matching the result of the parallel execution analysis based on the history with the input JCS, a parallel executable part of the job step is extracted.
The job execution management unit secures resources such as an address space required for parallel execution based on the degree of parallelism notified from the JCS analysis unit, and assigns a job step to each address space as a job and executes the job. . The execution of each job step is managed by a job execution management unit, and after the execution is completed, the user is notified of the completion of the execution via a job receiving unit.
The history information collection unit collects job execution history information and file access history information in chronological order. The history information analysis unit obtains a job step that can be executed in parallel based on the access history information of the file.
As a result, job steps that can be executed in parallel in the job are extracted, and these job steps can be executed in parallel.
[0006]
【Example】
The present invention will be described with reference to examples.
In the first embodiment, in a job including a plurality of job steps, a job control statement that defines a program to be executed by the job and a file to be accessed includes a record that declares the start of each job step. Is described, and the job steps in one job are executed in parallel. In this case, the condition is described in advance in the record or the input job control statement is analyzed. A job step having no restriction on the file access order is extracted, and a condition for starting the job step is added to a record declaring the start of each job step.
The second embodiment compares a job control statement of a submitted job with an execution history of a previously executed job and an access history to a file to determine a condition under which a job step can start execution. Is a method for executing job steps in parallel.
[0007]
FIG. 1 is a functional block diagram of the present invention. First, the configuration of the present invention will be described with reference to FIG.
100 indicates a computer system. 100 includes a central processing unit (CPU) (200) for performing arithmetic operations and a memory (300). Reference numeral 400 denotes an external storage device. 400 stores a job control statement defining a program to be executed by a job and a file to be accessed. 500 is also an external storage device. The history information collection unit 6000 outputs job execution history information and file access history information to the file 500.
Reference numeral 1000 denotes a JCS analysis unit. The JCS analysis unit inputs a job control statement (JCS) of the input job from 400, and obtains an access order relationship to the file from the JCS and a constraint condition for starting execution of each job step. By collating with the analysis result of (7000), a constraint condition for starting execution of each job step of the input JCS is added, and the result is transferred to the job receiving unit (2000).
The job accepting unit determines the maximum multiplicity at which the job steps can be executed in parallel with respect to the JCS passed from the JCS analyzing unit, and passes the maximum multiplicity with the JCS to the job step execution processing unit (3000).
The job step execution processing unit (3000) secures resources (address space) necessary for parallel execution, and executes the job steps one after another from the job step for which the restriction on the execution start has been released.
At 4000, a notification is received each time the execution of the job step ends, and it is confirmed whether the job to which the notified job step belongs has ended. When the process has been completed, the job completion unit 5000 is notified, and when there is a job step which has not yet started execution in another job step, the job step execution processing unit is called.
6000 is a history information collection unit. In step 6000, when the job is started, job start information is received from the job receiving unit (2000), and when the job step is completed, the job step end information and the file access history information of the job step are received. Received from the department (4000). Further, when the job is completed, job completion information is received from the job completion section (5000). The history information collection unit (6000) stores such job execution history information and file access history information in the external storage device (500) in the order of collection.
The execution history analysis unit (7000) receives the execution history (500) collected by the 6000 as an input, and restricts the start of execution of the job step based on the order of access to the file and the identification of input / output to the file. Find conditions. Job steps can be executed as soon as the file to be referenced is completed if the file to be referenced is completed. can do. A program execution unit 8000 executes a job step.
[0008]
FIG. 2 is a description example of the JCS described in the present invention. The description rules of JCS in this embodiment will be described with reference to FIG.
First. JOB is a control statement that declares a job as one processing unit. In this example, JOB1 is a job name.
In this job, a program called PGM1 is executed, then PGM2 is executed, and then PGM3 is executed. Thus, the STEP statement declares the designation of the program to be executed in the job and the execution order of the program. The execution unit of the program declared in the STEP statement is a job step. That is, a job step is an execution unit of a job, and means the execution of one program.
At 410, a program called PGM1 is executed in a job step whose job step name is STEP1. After the job step is completed, a program called PGM2 is executed in the job step whose job step name is STEP2. Further, after the execution of STEP2 is completed, a program called PGM3 is executed in a job step whose job step name is STEP3.
Files may be accessed during the execution of each program. The FD statement specifies the file to be accessed during the execution of the program. In the FD statement, a file name to be accessed is specified by a FILE operand.
Thus, it is necessary to associate a file to be accessed defined in the JCS with a program. That is the FD name. In the example of 410, IN1, OUT1, IN2, OUT2, IN3, OUT3 are FD names. Whether access to the file defined here is input or output is specified in the program.
[0009]
Next, the flow of the process of 410 will be described.
First, in STEP1, a program called PGM1 is executed. Here, A. Data is input from a file called DATA. The execution result is output to a file named DATA. Next, in STEP2, a program called PGM2 was created. Execute. here , PGM1, which is the execution result. Data of a file named DATA is input, and the execution result is set to C.DATA. Output to a file called DATA. After the execution of STEP2 is completed, a program called PGM3 is executed in STEP3. Here, the B.M. Data of a file named DATA is input, and the execution result is Output to a file called DATA.
Here, STEP2 and STEP3 are mutually B.D. Although a file named DATA is referred to, B. If the access to DATA is known to be an input, there is no data transfer relationship between STEP2 and STEP3, so that execution can be performed in parallel. However, B.I. If access to DATA is not known as input, it cannot be performed in parallel. Therefore, in the case of such a job step configuration, if there is no data transfer relationship between STEP 2 and STEP 3 after the execution of STEP 1 is completed, by executing these in parallel, the processing time is reduced. Is the object of the present invention.
[0010]
With reference to FIG. 3, a designation method for executing STEP2 and STEP3 of 410 in parallel will be described. This is the description rule in the present embodiment.
In 420, the specification of EXEC = STEP1 is added to the STEP sentences of STEP2 and STEP3. This declares an execution start condition indicating that execution can be started when the execution of the job step STEP1 is completed. This declaration may be made in advance by JCS.
In this embodiment, if the above-mentioned execution start condition is not declared in the JCS, an execution start condition which is a condition under which execution can be started by the JCS analyzer 1000 based on the input JCS is added to the operand of the STEP statement. Have to be able to.
The above is the description of the configuration and the job control statement description rules in the present embodiment.
[0011]
Next, a first embodiment will be described.
FIG. 4 is a flowchart of the JCS analysis unit.
First, all the JCSs of the input job are read (1005).
Next, it is checked whether or not there is a STEP statement specifying the EXEC operand for the JCS (1010).
If there is, the process branches to 1060 and passes the JCS to the job receiving unit. If not, input JCS line by line To analyze . First, the analysis target is set to the first line of the JCS (1015).
If the analysis target is a JOB sentence, the process proceeds to 1055, where the analysis target is the next one line. If it is not a JOB sentence, the process proceeds to 1025 to check whether it is a STEP sentence. If it is a STEP sentence, the process proceeds to 1030, where the address of the STEP sentence (the address where the STEP sentence is stored) is stored, and the process proceeds to 1055. If it is not a STEP statement, the remaining specification is an FD statement that specifies a file to be accessed.
Therefore, in 1035, an FD sentence specifying a file name equal to the FD sentence is searched from the preceding job step to the upper job step. When it is found first, the process proceeds to 1045, and when it is not found, the process branches to 1055 to set the analysis target in the next first line (1040).
At 1045, an EXEC operand is added to the STEP statement stored at 1030, and a job step name specifying an FD statement indicating the same file name retrieved at 1035 is designated.
Next, at 1050, it is checked whether the above analysis has been performed for all the input JCSs. If the analysis has been performed, the process proceeds to 1060 and the JCS is passed to the job receiving unit. If the search has not been performed, the process proceeds to 1055, and the above analysis is repeated with the target of analysis set as the next line.
[0012]
Next, the processing of the job receiving unit (2000) will be described with reference to FIG. FIG. 5 is a flowchart of the job execution receiving unit.
First, in 2005, the JCS is received from the JCS analysis unit.
Next, in 2010, the degree of parallelism of the job step is obtained. This is the maximum value of the number of STEP statements in which the execution start conditions of the input JCS EXEC operands are equal or the execution operands are not specified in the EXEC operand (STEPs in which the EXEC operand is not specified can be processed in parallel. is there).
Next, a job start record, which is execution history information, is created and passed to the history information collection unit (2015). Finally, a JCS table for monitoring the job execution status is created, and is linked to the last entry of the queue of the waiting JCS table pointed by the execution management master table. Here, the details of the job start record, the JCS table, and the execution management master table will be described later.
[0013]
FIG. 6 shows the structure of a table used by the job receiving unit (2000), the job step execution processing unit (3000), the step end receiving unit (4000), and the job completion unit (5000).
The execution management master table (3100) is a master table for monitoring a job execution status and managing a space in which a job can be executed.
The execution space management table (3200) is a table describing the job currently being executed. If the job is being executed, it is linked to the queue pointed from the JCS table (3300) of the corresponding job. , An empty execution space management table queue pointed by 3110 and 3120 in the execution management master table (3100).
The JCS table is a table for managing the contents of the JCS of each job and the execution space management table (3200) corresponding to the used space.
During the execution of the job, it is connected to the running JCS table queue pointed by 3130 and 3140, and when it is waiting for execution, it is connected to the JCS queue waiting for execution pointed to by 31503160. By passing the JCS table (3300) and the execution space management table (3200) to the program execution unit, one job step is executed on the space corresponding to the execution space management table (3200).
[0014]
FIG. 7 shows details of the execution space management table.
3210 and 3220 are pointers for generating queues managed by the execution management master table (3100) and the JCS table (3200). An area 3230 stores a job name to be executed, and an area 3240 stores a job step name. Reference numeral 3250 denotes a flag indicating an execution state, which is turned on during execution and turned off when not executed. 3260 is the number of the corresponding address space.
FIG. 8 shows the structure of the JCS table (3300). The JCS table is a table created for each job.
3310 and 3320 are pointers for generating a JCS table queue managed by the execution management master table.
Reference numerals 3330 and 3340 are pointers for managing queues of the execution space management table secured for executing the job step.
Reference numeral 3350 denotes a job step completion mask. From the upper job step, 2 bits are allocated left-justified. When these two bits are '00', it means not executed, and '10' means being executed. Further, when the execution is completed, it becomes "11".
Reference numeral 3360 denotes a storage area for the number of job steps. Reference numeral 3370 denotes an area for storing the degree of parallelism obtained by the job receiving unit 2010. An area 3380 stores the contents of the JCS.
[0015]
The flow of the job step execution processing unit will be described with reference to FIG. First, the number of entries in the free execution space management table queue is determined by 3010.
Next, in step 3020, a JCS table having a smaller parallelism (3370) than the number of entries obtained in step 3010 is searched from the head of the JCS queue waiting to be executed. If not, return to 3010 at 3030. In this case, the process may return to 3010 after waiting for a certain time interval.
If it is found that the number is 3030, the execution space management table corresponding to the degree of parallelism in the JCS table is separated from the empty queue in 3040, and 3110 and 3120 are updated. A connection is made to the execution space management table queue managed by the JCS table obtained in 3020. 3330 and 3340 are used for managing this queue. Reference numeral 3040 denotes an entry point when called by the step end receiving unit.
Next, in 3050, the analysis is advanced from the contents of the JCS (3380) from the upper STEP statement, and a job step that can be executed is searched. This search condition is
(1) A job step for which no EXEC operand is specified in the STEP statement and which has not been executed yet
Or
(2) The job step specified by the EXEC operand of the STEP statement is a job step that has already been executed
It is. Here, the execution status of the job step can be confirmed by referring to the field corresponding to each job step in the job step mask (3350).
At 3060, the executable job name and the job step name are stored in 3230 and 3240, respectively, and the execution flag (3250) is turned ON.
In step 3070, the corresponding field of the job step completion mask (3350) corresponding to the registered job step name is set to “10” to be in execution, and the updated execution space management table (3200) and JCS table (3300) are executed. Hand over to the department (8000).
The program execution unit executes the job step on the space number (3260) described in the execution space management table.
[0016]
Next, the step end receiving unit will be described with reference to FIG.
When the job step is completed, a notification is received from the program execution unit (8000).
First, the field of the job step completion mask (3350) corresponding to the job step notified of the execution completion in 4010 is set to '11'.
At 4020, the job name (3230) and job step name (3240) of the execution space management table (3200) that have been completed are cleared, and the execution flag (3250) is turned off.
Next, in 4030, a job step end record is created as an execution history and passed to the history information collection unit (6000).
Next, at 4040, the job step completion mask (3350) is looked at by 2 bits from the left for the number of job steps (3360) times to check whether there is a field set to '00'. In some cases, it means that there is a job step whose execution has not been started yet, so the process proceeds to 4070 to call the job step execution processing unit (proceed to step 3040 in FIG. 9).
If it does not exist, the job step completion mask (3350) is checked at 4050 by two bits from the left for the number of job steps (3360) times to check whether there is a field of '10'. If it exists, it means that there is still a job step being executed. Therefore, the execution of 4050 is repeated until there is no field of “10”. If there is no field with “10” in 4050, it means that all job steps have been executed. At 4060 Pass control to job completion section.
[0017]
Finally, the flow of the job completion unit (5000) will be described with reference to FIG.
First, in step 5010, a job end record is created as an execution history and passed to the history information collection unit (6000).
Next, in 5020, the execution space management table (3200) managed in the JCS table (3300) is connected to the empty queue managed by 3110 and 3120 in the execution management master table (3100).
Finally, the JCS table is released.
[0018]
Next, a second embodiment will be described.
In the second embodiment, parallel execution of job steps is analyzed based on past job execution history information and file access history information, and the results are used to execute the job steps in parallel.
Batch processing includes batch processing in which data is collected in units of one day, one week, one month, and the like, and processed collectively. , The same job is executed. In such a case, the second embodiment is effective.
In the first embodiment, when an execution start condition is obtained by the JCS analysis unit, whether a file access is an input or an output is specified in a program, so that it is impossible to identify whether the file access is an input or an output. Therefore, when the JCS shown in FIG. 2 is input, the EXEC operand of STEP2 becomes EXEC = STEP1, and the EXEC operand of STEP3 becomes EXEC = STEP2, and eventually the job steps are executed sequentially.
When the second embodiment shown here is used, the EXEC operand of STEP3 becomes EXEC = STEP1, and after the execution of STEP1 is completed, STEP2 and STEP3 can be executed in parallel.
The second embodiment differs from the first embodiment in that an execution history analysis unit (7000) is added and the flow of the JCS analysis unit (1000) is different.
[0019]
In the description of the present embodiment, first, details of a job execution history record and a file access history record will be described, and then, a flow of an execution history analysis unit using the history information will be described. Finally, the flow of the JCS analysis unit will be described.
The history information will be described with reference to FIG. 12, FIG. 13, FIG. 14, and FIG.
When the execution of the job is started, the job receiving unit (2000) outputs the job start information (510), and when the execution of the job ends, the job completion unit (5000) outputs the job end information (520).
Further, when the job step is completed during the execution of the job, the step completion receiving unit (4000) outputs the job step completion information (530).
When the program executed in each job step issues an instruction (CLOSE instruction) declaring the end of access, file access history information (540) is output for the closed file.
Each record has an identifier in the record in order to distinguish the type of information. The job start information (510) is X'01 '(511), the job end information (520) is X'02' (521), and the job step information (530) is X'03 '. The file access history information (540) differs depending on whether the program has input or output file data. The identifier (541) is X'04 'for input and X'05' for output.
Each of the above information is passed to the history information collection unit (6000) in time series every time an event occurs, and the history information collection unit (6000) outputs the information to the external storage device (500).
[0020]
Hereinafter, the output record format of each information will be described.
FIG. 12 shows the record format of the job start information.
The record is output by the job receiving unit (2000) when the execution of the job is started. 511 is an identifier, and the record is X'01 '. Reference numeral 512 denotes a job name. 513 is a job start time.
FIG. 13 shows the record format of the job end information.
521 is an identifier, and the record is X'02 '. 522 is a job name. 523 indicates the start time of the job execution, and 524 indicates the end time of the job execution.
FIG. 14 shows the record format of the job step end information.
531 is an identifier, which is X'03 'in the record. 532 is the name of the job to which the completed job step belongs. 533 is the start time of the job to which the finished job step belongs. 534 is a job step name. 535 is the start time of the job step, and 536 is the end time of the job step.
FIG. 15 shows the record format of the file access history information.
This record is output when the program issues a CLOSE instruction. 541 is an identifier. However, the contents of the identifier (541) are different depending on whether the program inputs data from a file or outputs data. X'04 'for input and X'05' for output.
542 is the job name of the job to which the program that accessed the file belongs. Reference numeral 543 denotes a start time of the job. 544 is the job step name of the job step executed by the program that accessed the file. 545 is the start time of the job step. 546 is the FD name. Reference numeral 547 denotes a file name which is an identifier of the file.
[0021]
The execution analysis unit (7000) obtains an execution start condition of each job step using the history information.
FIG. 16 shows the configuration of the execution history analysis unit (7000).
The execution history analysis unit (7000) is divided into history information input (7100) and execution condition analysis (7200). In the history information input (7100), the above-mentioned history information is input, and the job, the job step, and the file accessed by the job step are input. Relate. In the execution condition analysis (7200), an execution start condition is obtained for each job step from the result associated with the history information input (7100).
[0022]
17 to 22 show the relationships between the tables used in the execution history analysis unit and the details of each table.
FIG. 17 is a table relation diagram of a table group prepared for storing and analyzing the history information input by the execution condition analysis (7200). Details of each table are shown in FIGS.
The history master table (MSTH) (7500) is stored in the execution history analysis unit. (7000) It is a master table that manages a JOBH (7600) queue that stores job execution history and an execution condition table (7900) that stores execution start conditions for each job step.
The job execution history table (JOBH) (7600) is created for each job, and stores job start information (510) and job end information (520). The job (7600) queue follows the job execution order. Further, it manages a job step execution history table (STPH) (7700) queue that stores information on job step executed in the job.
The STPH (7700) is created for each job step, and is arranged in a queue in the order of execution within the same job. The STPH (7700) stores start information and end information of a job step. Further, the STPH (7700) manages a file access history table FDH (7800) queue that stores information of the file accessed in the job step.
The FDH (7800) is created for each file accessed by the program, and stores file information of an access destination. The FDH (7800) creates a queue for each job step executed by the program.
The execution condition table (EXCN) (7900) stores conditions under which execution can be started for all job steps stored in the history information.
[0023]
18 to 22 show details of the table described above.
FIG. 18 is a table structure of the history master table (MSTH) (7600).
The MSTH is a master table that manages a JOBH queue and an EXCN queue. The MSTH (7500) stores a first JOBH address (7510), a last JOBH address (7520), and an EXCN address storage area (7530).
FIG. 19 shows a table structure of JOBH (7600).
JOBH is created when the job start information (510) is input. 7610 is Next JOBH This is an address storage area, and reference numeral 7620 is a previous JOBH address storage area. The cues are formed using 7610 and 7620. Reference numeral 7630 denotes a first STPH address storage area, and reference numeral 7640 denotes a last STPH address storage area. Reference numerals 7630 and 7640 manage an STPH queue that stores job step information executed in a job corresponding to JOBH.
Reference numeral 7650 denotes a storage area for the job start time, and reference numeral 7660 denotes a storage area for the end time of the job. Reference numeral 7670 denotes a job name storage area. 7650 and 7670 are copied from the job start information record (510). 7660 is copied from the job end information record (520).
[0024]
FIG. 20 is a table structure of STPH (7700).
The STPH (7800) is created when the file access history information (540) is input and the STPH (7700) to which the program accessing the file belongs does not exist.
7710 is a storage area for the next STPH table address, and 7720 is a storage area for the previous STPH table address. 7710 and 7720 form an STPH queue that manages job steps executed in job units. Reference numeral 7730 denotes a head FDH address storage area, and reference numeral 7740 denotes a final FDH address storage area. Reference numerals 7730 and 7740 manage an FDH queue for storing file information accessed in a job step. Reference numeral 7750 denotes a storage area for the job step name. Reference numeral 7760 denotes a job step start time storage area, and reference numeral 7770 denotes a job step end time storage area.
FIG. 21 shows a table structure of FDH (7800).
The FDH (7800) is created when the file access history information (540) is input. FDH ( 7800 ) Is managed for each job step in which the program accessing the file is executed. Reference numeral 7810 denotes a next FDH address storage area, and reference numeral 7820 denotes a previous FDH address storage area. An FDH queue is created using 7810 and 7820. Reference numeral 7830 denotes a storage area of the FD name described in JCS. Similarly, 7840 is a storage area for file names. Reference numeral 7850 denotes an input / output identifier storage area.
FIG. 22 is a table structure of the execution condition table (EXCN) (7900).
7910 describes a job name, and 7920 describes a job step name executed in the job. Furthermore, 7930 stores a condition for starting execution, that is, a job step name that must be ended to start the job step.
[0025]
FIG. 23 is a flow of history information input (7100).
First, one history information record is input (7105). At 7110, it is checked whether or not the input record is the job start information record (510). That is, it is checked whether or not the identifier (511) is X'01 '. If the identifier (511) is X'01 ', the flow advances to 7115 to create a job (7600). Here, the job start time (7650) and the job name (7670) are registered in JOBH (7600). The created JOBH is managed by 7510 and 7520 JOB Register in the queue.
If the identifier is not X'01 'in step 7110, the flow advances to step 7120. At 7120, it is checked whether or not the input record is a file access history information record (540). That is, it is checked whether or not the identifier (541) of the input record is X'04 'or X'05'. If the input record satisfies the above condition, the process proceeds to 7125; otherwise, the process proceeds to 7135.
In 7125, first, the JOBH (7600) queue managed by the 7510 and 7520 is traced to search for a JOBH (7600) satisfying the following conditions.
(1) The job name (542) of the input record is equal to the job name (7670) of JOBH (7600).
(2) Job start time (543) of the input record and JOBH (7600)
The job start time (7650) is equal.
(3) The job end time (536) has not been registered.
In the JOBH search processing, the start information record (510) of the job to which the program that accessed the file described in the input record belongs already exists. Output to system In the JOBH search processing, there is always a JOBH (7600) satisfying the above three conditions in the JOBH queue.
Next, an STPH (7700) that satisfies the following three conditions is searched from the STPH (7700) queue managed by the JOBH (7600) obtained by the JOBH search processing.
(1) The job step name (544) of the input record is equal to the job step name (7750) of the STPH (7700).
(2) The job step start time (545) of the input record is equal to the job step start time (7760) of STPH (770).
(3) The job step end date and end time (7700) have not been registered.
If the STPH search process fails to search for an STPH that satisfies the three conditions, a new STPH area is secured, and the job step name (542) and the job step start time (544) are entered from the input record. make a copy. Thereafter, the STPH to be operated in this step is set as the STPH, and the process proceeds to 7130.
If the STPH (7770) that satisfies the above three conditions can be found in the STPH search process, the process proceeds to 7130 with the searched STPH (7700) as an operation target.
At 7130, first, an FDH area is secured. For the secured FDH (7800), the FD name (546), the file name (547), and the input / output identifier (548) are registered from the input record information. Here, the identifier (548) of the file access history information record (540) is copied to the input / output identifier (7860). The FDH that has been registered is connected to the end of the FDH queue managed by the STPH (7700) that has been operated in the STPH search process.
[0026]
7135 Check whether the input record is a job step end information record. That is, it is checked whether the identifier of the input record is X'03 '.
If the identifier of the input record is X'03 ', the flow advances to 7140. In step 7140, the JOBH (7600) that satisfies the following three conditions is searched from the JOBH queue managed by the MSTH (7500).
(1) The job name (532) of the input record is equal to the job name (7670) of JOBH.
(2) The job start time (532) of the input record is equal to the job start time (7650) of JOBH.
(3) The job end time (7660) of JOBH (7600) has not been registered.
In the JOBH search process, the job start information record (510) to which the job step described in the input record belongs has already been output, and the JOBH (7600) corresponding to the job start information record (510) has been created. is there.
Next, in the STPH (7700) queue managed by the searched JOBH (7600), an STPH (7700) satisfying the following three conditions is searched.
(1) The job step name (534) of the input record is equal to the job step name (7750) of the STPH (7700).
(2) The job step start time (535) of the input record is equal to the job step start time (7760) of STPH (770).
(3) The job step end time (7770) of STPH (7700) has not been registered.
In the search process of the STPH (7700), when the STPH that satisfies the above three conditions can be searched, the job step end time (536) is registered in the STPH (7700) from the input records.
[0027]
If the STPH (7700) that satisfies the condition cannot be searched in the STPH search processing, a new STPH area is secured, and information corresponding to the areas 534 to 536 is copied based on the information of the input record. Next, the STPH is connected to the end of the STPH queue managed by the searched JOBH by the JOBH (7700).
In 7135, if the identifier of the input record is not X'03 ', the flow advances to 7145. At 7145, it is checked whether the input record is a job end information record. That is, it is checked whether or not the identifier of the input record is X'02 '. If the identifier of the input record is X'02 ', the flow advances to 7150. In 7150, first, a job (7500) that satisfies the following three conditions is searched.
(1) The job name (522) of the input record is equal to the job name (7670) of JOBH.
(2) The job start time (523) of the input record is equal to the job start time (7650) of JOBH (7600).
(3) The job end time (7660) of JOBH (7600) has not been registered.
In the JOBH search processing, the job start information record (510) corresponding to the job end information described in the input record has been output, and the OS application job search means (1300) has corresponded to the job start information record (300). JOBH to be created has already been created. Therefore, in the JOBH search processing, there is always a JOBH that satisfies the above three conditions.
Next, the job end time (524) is registered for the JOBH obtained in the JOBH search process from the input record.
[0028]
If it is determined in step 7145 that the input record is not the job end information record, the process advances to step 7155. Similarly, after completing the processes in 7130, 7140, and 7150, the process proceeds to 7155. At 7155, it is checked whether the record input this time is the last record. In the case of the last record, the input processing of the system operation information is completed. If it is not the last record, the flow advances to step 7105 to input the next record and perform the same processing.
As a result, the relationship between the job and the job step and the relationship between the job step and the accessed file could be related. Using this, the execution start condition of each job step is obtained, and EXCN (7900) is created.
[0029]
The flow of the execution condition analysis will be described with reference to FIG.
First, the analysis target is set to the first entry of the JOBH queue (7205). First, a job to be analyzed is selected.
Next, the job step execution start condition is determined by examining the files accessed by the job steps belonging to the job to be analyzed one by one. Therefore, in 7210, in order to determine the analysis target as the final job step, the last entry in the STPH queue managed by the job to be analyzed is set as the analysis target.
At 7215, it is checked whether or not the STPH to be analyzed is the first entry. If it is the first entry, the process proceeds to 7250. Otherwise, proceed to 7220.
In 7220, an FDH whose input / output identifier is an input is searched from among the FDHs managed by the STPH that has been analyzed. This may be more than one. As a result of the determination in 7225, if there is, the process proceeds to 7230; otherwise, the process proceeds to 7245.
In 7230, the FDH whose file name is the same as the searched FDH and whose input / output identifier is an output is searched from the preceding stage of the STPH currently being analyzed to the upper stage STPH. If yes, go to 7240; otherwise, go to 7245.
As a result of the search in 7230 and 7235, if there is an STPH that satisfies the above condition, the execution of the job step corresponding to the STPH to be analyzed starts unless the job step corresponding to the STPH searched in 7230 ends. Can not do it. In step 7240, the job name, the job step name, and the job step name searched in step 7230 are registered in the EXCN (7900).
In step 7245, the process returns to step 7215 with the preceding STPH as an analysis target in order to check the execution conditions of the next job step.
At 7250 branched from 7215, before the next job is analyzed, it is checked whether the JOBH currently being analyzed is the last entry in the JOBH queue, and if it is the last entry, the process ends. If it is not the last entry, the flow advances to 7255, and the next JOBH is analyzed, and the flow returns to 7210.
Based on the EXCN (7900) obtained by the execution history analysis unit (7000), the JCS analysis unit adds the execution conditions of the job step to the input JCS and passes it to the job reception unit.
[0030]
The flow of the JCS analysis unit will be described with reference to FIG.
First, the JCS of one job statement is read by 10005. In step 10010, an entry having the same job name as the JCS input from EXCN (7900) is searched.
If it does not exist, the process branches from 10015 to 10055, and passes the JCS to the job receiving unit (2000).
If there is, the process proceeds to 10020, and the entry searched in 10010 is narrowed down to the analysis target. In step 10025, the second STEP sentence in the JCS is set as an analysis target.
In step 10030, an entry equal to the job step name indicated in the STEP statement is searched from the EXCN entry to be analyzed.
If it exists, the process proceeds to 10040, and if it does not exist, the process proceeds to 10045 (10035).
In 10040, an EXEC operand is added to the STEP statement, Searched The execution condition of EXCN is specified in the parameter of the EXEC operand.
In step 10045, it is checked whether the above search has been performed for all the STEP sentences. If not all STEP statements have been analyzed yet, the process proceeds to 10050, where the next STEP statement is analyzed, and the process returns to 10030.
[0031]
【The invention's effect】
According to the present invention, in a job composed of a plurality of job steps, job steps having no file transfer relationship can be executed in parallel, so that the execution time of the job can be reduced.
[Brief description of the drawings]
FIG. 1 is a functional block diagram showing a configuration of the present invention.
FIG. 2 is a diagram illustrating an example of a job control statement.
FIG. 3 is a diagram illustrating an example of a job control statement when the present invention is used.
FIG. 4 is a diagram illustrating a flowchart of a JCS analysis unit in the first embodiment.
FIG. 5 is a diagram illustrating a flowchart of a job receiving unit.
FIG. 6 is a diagram illustrating a table relation of tables used by a job receiving unit, a job step execution processing unit, a step end receiving unit, and a job completion unit.
FIG. 7 is a diagram showing a table structure of an execution space management table.
FIG. 8 is a diagram showing a table structure of a JCS table.
FIG. 9 is a diagram illustrating a flowchart of a job step execution processing unit.
FIG. 10 is a diagram illustrating a flowchart of a step end receiving unit.
FIG. 11 is a diagram illustrating a flowchart of a job completion unit.
FIG. 12 is a diagram illustrating a structure of a job start information record referred to in the second embodiment.
FIG. 13 is a diagram showing a structure of a job end information record.
FIG. 14 is a diagram showing the structure of a job step end information record.
FIG. 15 is a diagram showing a structure of a file access history information record.
FIG. 16 is a diagram illustrating a flowchart of an execution history analysis unit according to the second embodiment.
FIG. 17 is a diagram showing a relation between tables used in the execution history analysis unit.
FIG. 18 is a diagram showing a structure of a history master table.
FIG. 19 is a diagram showing a structure of a job execution history table.
FIG. 20 is a diagram showing a structure of a job step execution history table.
FIG. 21 is a diagram showing a structure of a file access history table.
FIG. 22 is a diagram showing the structure of an execution condition table.
FIG. 23 is a diagram illustrating a flowchart of history information input in the second embodiment.
FIG. 24 is a diagram illustrating a flowchart of execution condition analysis in the second embodiment.
FIG. 25 is a diagram illustrating a flowchart of a JCS analyzer in the second embodiment.
[Explanation of symbols]
100 computer system
200 central processing unit
300 memory
400 External storage device for storing job control statements
500 External storage device for storing execution history
510 Job start information record
520 Job end information record
530 Job step end information record
540 File access history information record
1000 JCS analysis unit
2000 Job reception unit
3000 Job step execution processing unit
3100 Execution management master table
3200 execution space management table
3300 JCS table
4000 Step end reception unit
5000 Job Completion Department
6000 History information collection unit
7000 execution history analysis unit
7500 History master table
7600 Job execution history table
7700 Job step execution history table
7800 File access history table
7900 Execution condition table

Claims

A program to be executed by using a job control statement (JCS) and resources to be used by the program are specified.
In a computer system that accesses a file and executes a plurality of jobs composed of a plurality of job steps in parallel or sequentially,
For each job step, a parameter for specifying an execution start condition which is a condition for starting execution is provided in JCS,
When a job is submitted, enter the JCS that defines the job,
By calculating the maximum value of the total number of job steps having the same contents of the parameter and the number of unspecified job steps from all the job steps of the job, the maximum value of the job steps that can be executed in parallel (maximum parallel Degree), and
Securing resources for the programs of the maximum degree of parallelism to be executed in parallel;
Allowing execution of a job step satisfying an execution start condition in the job;
A job execution control method for monitoring the execution status of all the job steps and releasing the secured resources when all the job steps have completed execution.

The job execution control method according to claim 1,
When a job is submitted, enter the JCS that defines the job,
Requesting a pair of job steps accessing the same file by referring to a file identifier accessed by each job step defined in the JCS;
In the paired job steps, the execution order of the job step defined by the JCS, which is later in execution order, is defined as after completion of execution of the other paired job step as the execution start condition. Determining an execution start condition;
A step of writing the determined execution start condition as a parameter in the input JCS.

The job execution control method according to claim 1,
When the job is executed,
A job identifier,
An identifier for the job step,
The start time of the job step,
All file identifiers accessed,
Collecting history information including an access type indicating whether access to all the accessed files was output or input;
In the same job,
The file identifiers are equal, and
The access types are output and input, and
Obtaining a pair of job steps in which the start time of the job step whose output is the access type is earlier than the start time of the job step whose input is the access type;
Determining an execution start condition that defines an execution start condition of the job step whose input is the access type as immediately after completion of the job step whose output is the access type, and saving;
And a step of writing the stored execution start condition as a parameter to the input JCS when the same job as the job is input again.