JPH1040123A - ジョブ管理方式と方法 - Google Patents

Abstract

(57)【要約】 【課題】 データベースシステムにおいて、障害発生
後にデータベースの更新状態を調査することなく、中断
したジョブを再起動できるジョブ管理方式を提供する。 【解決手段】 ジョブｎ（０１０）の起動中、ジョブ
管理モニタ（１００）はジョブｎの進捗状況やデータベ
ースモニタ（０２０）からのデータベース使用状況を管
理テーブルデータ入出力手段（１２０）を通してジョブ
管理テーブル（１４０）へジョブステップごとにステッ
プ管理テーブル（１４１）を記録する。障害発生時、ジ
ョブ再起動手段（１３０）はジョブ管理モニタを通して
障害発生前の状況を再現して、中断したジョブを再起動
する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はジョブ管理方式、特
に、汎用コンピュータにおいて、データベースを利用し
ているときのシステム障害発生時に、障害原因の究明及
び復旧作業が完了した後に迅速かつ平易で高い信頼性の
もとで、ジョブの再起動が行なえるジョブ管理方式と方
法に関する。

【０００２】

【従来の技術】ジョブ管理とは、コンピュータシステム
上でどのジョブが稼働中であり、メモリやハードディス
ク等のコンピュータ資源をどの程度使用（占有）してい
るか等を管理し、コンピュータシステムを効率良く稼働
・運用するためのものである。

【０００３】ハードディスク等の物理的な損傷による障
害が発生し、コンピュータシステムとして現在実行して
いるジョブの稼働を継続することができなくなったと
き、稼働中であったジョブに対して、運用者がジョブを
再起動する場合、稼働中であったジョブやプログラムの
進捗状況を調査し、ジョブで使用していたマスタデータ
とトランザクションデータの更新状況などにより、再起
動をかけるためのマスタデータやトランザクションデー
タを再準備する必要がある。これらの調査及びデータの
準備作業は非常に煩雑であった。

【０００４】このような問題の対策として、特開平５−
２３３３４２号公報、平４−１７５８３０号公報等が提
案されている。上記特開平５−２３３３４２号公報はコ
ンピュータシステムにおいて、ジョブの実行中に障害が
発生して処理が中断されたとき、障害の復旧後、そのジ
ョブを再起動させるときのジョブ再スタート制御方式に
関するもので、データベースを更新するジョブを実行す
るとき、自己のジョブに対応する再スタートファイルに
定期的に再スタートアドレスを書き込んでおき、コンピ
ュータシステムに何らかの障害が発生し、障害を復旧後
にジョブの再起動をかけるとき、前記再スタートファイ
ルを参照して自己のジョブに対応する前記再スタートア
ドレスから直ちに更新処理を再開することにより、中断
したジョブを最初から実行し直す必要がないため、時間
の消費削減することができるとしている。

【０００５】また、前記平４−１７５８３０号公報にお
いては、コンピュータシステムの処理中に異常が発生し
たときに、その原因を取り除いた後のジョブの再実行を
効率的に制御する再実行制御方式に関するもので、コン
ピュータシステムの処理中に障害が発生して処理を中断
したとき、その原因を取り除いた後に中断したジョブの
再実行を行なわせる再実行制御方式において、実行中の
ジョブ内の各ステップの実行状況を記録したジョブ情報
と実行中のステップ内の各処理単位の実行状況及び必要
な処理結果を記録したステップ情報とを有し、ジョブの
実行状況を管理するジョブ管理レコードを不揮発性のメ
モリに設け、中断したジョブを再開する際に前記ジョブ
管理レコードを参照して正常に終了したステップ及び処
理単位を重複して再実行することなく中断したステップ
中の中断した処理単位から効率的に再実行を行なうこと
ができるとしている。

【０００６】

【発明が解決しようとする課題】前述の従来技術である
特開平５−２３３３４２号公報においては、つぎのよう
な問題点がある。

【０００７】第一の問題点は、データベースシステムに
おいて、複数のプログラムより検索要求や更新要求が出
される場合が多く、一つのプログラムから更新命令が発
行されたときに、他のプログラムから更新対象データへ
の検索要求が発行された場合、検索結果を保証するため
に、更新対象データを他のプログラムから使用できなく
させるロック処理を行なったうえで、ハードディスク内
に存在するデータベースの更新処理を実施する（これ
を、物理更新という）。また、更新処理を含むプログラ
ム内で更新命令発行のたびに、ハードディスクをアクセ
スすることによって処理速度が著しく低下するため、更
新対象データをロック状態にして、メモリ上のデータの
みを更新し、ディスクへの更新は未処理で待機させる論
理更新がある。通常このようなデータベースシステムに
はデータベースモニタが存在し、メモリ上で論理更新さ
れたデータをハードディスク上へ物理的に更新する最適
な時期を監視しており、このデータベースモニタの指示
により物理更新処理が行われる。従って、論理更新と物
理更新のタイミングがｎ：１のようなデータベースシス
テムにおいては、再スタート情報の保存時期により、論
理更新された再スタートアドレスと物理更新された再ス
タートアドレスにズレが生じる可能性があり、再スター
ト処理の後、データベースシステムに矛盾が生じてジョ
ブ処理を続行できなくなってしまう。

【０００８】また、第二の問題点は、再起動をするとき
の再起動データとして、ジョブ名、ファイル名、データ
ベースの再スタートアドレスを書き込むようになってい
るが、プログラム内におけるワーク領域のデータ記録が
無いため、ジョブ再スタート制御方式ではワーク領域を
使用したプログラムでの運用はできなくなる。

【０００９】また、平４−１７５８３０号公報において
も、つぎのような問題点がある。

【００１０】第一の問題点として、特開平５−２３３３
４２号公報の第一の問題点と同様で、論理更新と物理更
新が１：１のデータベースシステムでしか使用できない
点である。つまり一つのプログラムが更新処理の命令を
発行すると即座にディスク内のデータベースを書き換え
るデータベースのみを対象にしていることである。

【００１１】第二の問題点は、再実行制御方式を実行す
るための再実行データとして、ジョブ情報とステップ情
報が必要になる。ジョブ情報はジョブ名、ステップ名、
処理の結果を通知するステータスの３項目を、ステップ
情報としてファイルの実行すべきポイントを示すカレン
ト情報とプログラム内のワーク情報である。更新データ
の入出力ごとに、前記ジョブ情報とステップ情報をジョ
ブ管理レコードとして書き換えている。つまり、発生ケ
ースとしては稀なシステム障害の予防手段として、通常
の処理中に前記処理がなされるとコンピュータ上の資源
を浪費するとともに処理時間の増加を招くことになる。

【００１２】［発明の目的］本発明の目的は、システム
障害発生後、障害原因を取り除いた後に、障害時のジョ
ブ実行状況、各ジョブ内のステップ処理進捗状況、ま
た、再処理可能なファイルデータの調査及び作成を行な
う必要のない簡易なジョブ管理方式を提供することであ
る。

【００１３】また、本発明の目的は、使用可能環境とし
ても通常ファイル、物理更新と論理更新が１：１または
１：ｎのデータベースシステムで使用可能となるジョブ
管理方式を提供することである。

【００１４】

【課題を解決するための手段】本発明のジョブ管理方式
は、コンピュータシステムにおける起動中のジョブが使
用する入力ファイル、マスタファイル、及び出力ファイ
ルと、データベースの状況を管理するデータベースモニ
タとを備えているジョブ管理方式において、実行中のジ
ョブ実行状況を監視するジョブ管理モニタと、ジョブ管
理情報を格納しておくジョブ管理テーブルと、前記デー
タベースモニタからのジョブステップ検出の情報を受け
る前記ジョブ管理モニタの指示により前記ジョブ管理テ
ーブルの情報を受け渡しする管理用テーブルデータ入出
力手段と、障害発生後に処理が中断されたジョブを起動
するジョブ再起動手段とで構成されることを特徴とす
る。また、本発明のジョブ管理方法は、コンピュータシ
ステムにおける起動中のジョブを複数のファイルとして
管理するジョブ管理モニタと、データベースの状況を管
理するデータベースモニタとを備えているジョブ管理方
法において、前記コンピュータシステムで前記データベ
ースとデータのやり取りを行う所定回数を前記データベ
ースモニタがカウントし、所定カウント毎に前記ジョブ
管理モニタに通知し、前記ジョブ管理モニタがその通知
毎にジョブ管理テーブル内の少なくともジョブ実行中の
ファイル状況を示すファイルポインタとジョブ作業の領
域を示す作業領域データとを更新し、前記コンピュータ
システムで障害が発生したときに、前記ジョブ管理モニ
タは前記ファイルポインタ及び前記作業領域データとを
前記ファイルに収納して再起動を行うことを特徴とす
る。さらに、該ジョブ管理方法において、前記ジョブ管
理テーブルはジョブＩＤとジョブステップを示すステッ
プＩＤと作業の開始・終了を示す処理フラグを備えたこ
とを特徴とする。

【００１５】［作用］管理用テーブルデータ入出力手段
によって作成、更新されるジョブ管理テーブルは起動中
のジョブごとにジョブ管理用テーブルが作成され、さら
にジョブのステップごとに処理の進捗状況が格納され
る。また、ジョブの各ステップで使用されているデータ
ファイルごとに処理ポインタを管理し、ジョブの各ステ
ップが実行中であるか、処理が終了したかを判定する処
理フラグも格納している。

【００１６】

【発明の実施の形態】

［第１実施形態］ 〔構成の説明〕図１を参照すると、本実施形態のジョブ
管理方式は、コンピュータ上で起動している個々のジョ
ブ１〜ｎ（０１０）と、データベースの動作を監視する
データベースモニタ（０２０）と、起動中のジョブ１〜
ｎが処理で使用する入力ファイルＡ（０１１）、マスタ
ファイルＢ（０１２）、出力ファイルＣ（０１３）等の
ファイル群（０３０）と、オペレーティングシステムや
データベースモニタからの通知を受け、動作するジョブ
管理モニタ（１００）と、ジョブ管理モニタ（１００）
からの制御により動作する管理用テーブルデータ入出力
手段（１２０）と、管理用テーブルデータ入出力手段
（１２０）によって管理されるジョブ単位のジョブ管理
テーブル（１４０）とを含んでいる。

【００１７】上記ジョブ管理テーブル（１４０）は、ジ
ョブのステップごとにプログラムの進捗状況を管理する
ステップ管理テーブル（１４１〜１４ｎ）を備えてい
る。

【００１８】図２のフローチャートを参照して、構成内
容をさらに説明する。任意のジョブｎが起動する（Ａ０
１）と、ジョブ管理モニタ（１００）がジョブｎの起動
を認識して、ジョブｎの実行状態の監視処理を開始する
（Ａ０２）。

【００１９】管理用テーブルデータ入出力手段（１２
０）は前記ジョブ管理モニタ（１００）を介してジョブ
ｎ用のジョブｎ管理テーブルの作成指示を出す（Ａ０
３）。

【００２０】前記ジョブｎの監視処理によりオペレーテ
ィングシステムからのステップ開始や終了通知、または
データベースモニタからの通知情報を待つ（Ａ０４）。

【００２１】前記ジョブｎの監視処理によりオペレーテ
ィングシステムやデータベースモニタからの通知の内容
により、ステップ開始通知やステップ終了通知、データ
ベースモニタよりの静止点確立情報通知、ジョブ終了通
知等があったかどうかの条件ブロックの判定を行なう
（Ｂ０１，Ｂ０２，Ｂ０３）。

【００２２】前記条件ブロックの判定により管理用テー
ブルデータ入出力手段はジョブｎ用管理テーブル１４ｎ
に必要な情報を出力する（Ａ０５）。

【００２３】前記条件ブロックの判定によりジョブの終
了通知を受けたとき、前記ジョブｎ管理テーブルの削除
処理を実施する（Ａ０６）。

【００２４】前記ジョブｎ管理テーブルの削除処理の完
了を待って、ジョブｎに対する監視処理を終了する（Ａ
０７）。

【００２５】〔動作の説明〕つぎに本発明の実施の形態
について図面を参照して説明する。図１は本発明の実施
の一形態としてのジョブ管理方式の構成図である。ま
た、図２は本発明の実施の一形態としてのジョブ管理方
式の流れを示す要素のジョブフローチャートである。

【００２６】まず、任意のジョブｎが起動する（図１の
０１０及び図２のＡ０１）と、ジョブ管理方式の要素で
あるジョブ管理モニタ（図１の１００）が認知してジョ
ブｎのモニタを開始する。

【００２７】前記ジョブ管理モニタ１００は管理用テー
ブルデータ出力手段（図１の１２０及び図２のＡ０３）
にジョブｎ用管理テーブル（図１の１４ｎ及び図２のＡ
０４）の作成指示を出す。前記ジョブ管理モニタ１００
が前記ジョブｎを監視している際に、オペレーティング
システムからのステップ開始と終了の通知（図２のＢ０
１）を待つとともに、データベースモニタ（図１の０２
０）からの静止点の確立情報があるかどうかの通知を待
つ。

【００２８】前記ジョブ管理モニタ１００は前記オペレ
ーティングシステムや前記データベースモニタからの通
知により、条件ブロック（図２のＢ０１，Ｂ０２，Ｂ０
３）の判定を行なう。

【００２９】前記ジョブ管理モニタ１００が前記オペレ
ーティングシステムからステップ開始の通知を受けた場
合（図２のＢ０１）、前記管理用テーブルデータ入出力
手段１２０により、ジョブ管理テーブル１４ｎ内にジョ
ブｎ用のステップｎテーブルを作成し、ジョブＩＤ、ス
テップＩＤ、ファイルレコードポインタ、処理データ、
処理フラグ（図１の１４ｎ）を出力する（図２のＡ０
５）。また、前記オペレーティングシステムからステッ
プ終了の通知を受けた場合（図２のＢ０１）、前記管理
用テーブルデータ入出力手段１２０により、前記ジョブ
管理テーブル１４ｎ内のジョブｎ用のステップｎテーブ
ルの処理フラグに終了フラグを出力する（図２のＡ０
５）。

【００３０】前記ジョブ管理モニタ１００が前記データ
ベースモニタ０２０から静止点の確立情報を受けた場合
（図２のＢ０２）、つまり物理更新の実施の通知を受け
た場合には、前記管理用テーブルデータ入出力手段１２
０により、前記ジョブ管理テーブル１４ｎ内のファイル
レコードポインタ及び作業領域データ（図１の１４ｎ）
を書き換える（図２のＡ０５）。

【００３１】前記ジョブ管理モニタ１００が前記オペレ
ーティングシステムよりジョブｎの終了通知を受けた場
合（図２のＢ０３）、前記管理用テーブルデータ入出力
手段１２０にジョブｎ用管理テーブル１４ｎの削除要求
を出す。

【００３２】削除要求を受けた前記管理用テーブルデー
タ入出力手段１２０はジョブ管理テーブル１４０内のジ
ョブｎ用管理テーブル１４ｎを削除する（図２のＡ０
６）。

【００３３】前記ジョブｎ用管理テーブル１４ｎの削除
が終了したら、前記ジョブ管理モニタ１００に終了通知
を出し、前記終了通知を受けたジョブ管理モニタ１００
はジョブｎの監視処理を終了する（図２のＡ０７）。

【００３４】ジョブ再起動手段（図１の１３０）は、前
記管理用テーブルデータ入出力手段１２０によりジョブ
管理テーブル１４０内の情報を検索し、処理フラグの終
了していないジョブを検出し、終了していないジョブが
存在していた場合、ジョブ管理テーブル１４０内の情報
を元に障害が発生する直前の環境を再現して再起動を実
施する。

【００３５】〔実施例〕次に、本実施形態の一実施例の
動作を詳細に説明する。図１を参照すると、ジョブ１
（０１０）は入力ファイルＡ（０１１）、マスタファイ
ルＢ（０１２）、出力ファイルＣ（０１３）をアサイン
し、前記入力ファイルＡ０１１のデータを元に、前記マ
スタファイルＢ０１２を更新し、前記出力ファイルＣ０
１３にデータを出力する処理である。

【００３６】例えば、前記マスタファイルＢ０１２は前
記入力ファイルＡ０１１のデータを２０件処理するごと
に、静止点を確立するよう設定されている。静止点の設
定はオペレータが任意に設定できる。

【００３７】オペレータにより前記ジョブ１が起動され
ると、ジョブ管理モニタ１００は前記ジョブ１の起動を
認識し、管理用テーブルデータ入出力手段１２０へジョ
ブ１用の管理テーブル１４０の作成を指示する。更に、
オペレーティングシステムから前記ジョブ１のステップ
１の開始通知を受けると、前記管理用テーブルデータ入
出力手段１２０へステップ管理テーブル１４１としてス
テップ１テーブルの作成を指示するとともにステップ情
報として、ジョブの種別を管理するジョブＩＤ（１４１
１）と、ジョブ内のステップの種別を管理するステップ
ＩＤ（１４１２）と、前記入力ファイルＡ０１１、前記
マスタファイルＢ０１２、前記出力ファイルＣ０１３の
進捗状況を管理するファイルレコードポインタ（１４１
３）と、ジョブ１の処理を行なう上で計算結果等のデー
タを格納する作業領域データ（１４１４）と、ステップ
ごとの処理状況を管理する処理フラグ（１４１５）とを
設定する。

【００３８】データベースモニタ（０２０）は前記オペ
レータの設定した静止点確立のための件数（この場合２
０件）を処理すると、静止点確立の通知（ｆ）を前記ジ
ョブ管理モニタ１００へ発行する。

【００３９】前記静止点確立の通知を受けたジョブ管理
モニタ１００は、前記管理用テーブルデータ入出力手段
１２０へ前記入力ファイルＡ０１１、前記マスタファイ
ルＢ０１２、前記出力ファイルＣ０１３のファイルレコ
ードポインタ１４１３と、前記作業領域データ１４１４
の書き換え指示を出す。

【００４０】前記管理用テーブルデータ入出力手段１２
０は、前記ジョブ管理テーブル１４０内の現在管理して
いるステップ１テーブル内のファイルレコードポインタ
１４１３と作業領域データ１４１４を前記書き換え指示
された値で更新する。

【００４１】ジョブ管理モニタ１００はデータベースモ
ニタ０２０からの静止点確立の通知を受けるたびに、前
記ファイルレコードポインタ１４１３と、前記作業領域
データ１４１４の更新処理を継続する。

【００４２】ジョブ管理モニタ１００がオペレーティン
グシステムからステップ１の終了通知を受けると、前記
管理用テーブルデータ入出力手段１２０へ前記処理フラ
グ１４１５の更新指示を出す。

【００４３】前記更新指示を受けた管理用テーブルデー
タ入出力手段１２０は、ジョブ管理テーブル１４０のス
テップ１テーブルの処理フラグ１４１５に処理終了を示
す値を設定する。

【００４４】ジョブ管理モニタ１００はオペレーティン
グシステムからステップ２の開始通知を受けると、前記
ステップ１で開始通知を受けた時と同様に、管理用テー
ブルデータ入出力手段１２０に、ジョブ管理テーブル１
４０のステップ２テーブルの作成指示を出す。

【００４５】以下、ステップｎの終了通知まで前記処理
を繰り返す。

【００４６】ジョブ管理モニタ１００がオペレーティン
グシステムからジョブ１の終了通知を受けると管理用テ
ーブルデータ入出力手段１２０へジョブ１のジョブ管理
テーブルの削除指示を出す。

【００４７】前記ジョブ１のジョブ管理テーブルの削除
指示を受けた管理用テーブルデータ入出力手段１２０
は、ジョブ管理テーブル１４０からジョブ１のジョブ管
理テーブルを全て削除する。

【００４８】前記ジョブ１のジョブ管理テーブル１４０
の削除が完了すると、ジョブ管理モニタ１００はジョブ
１の監視処理を終了する。

【００４９】前記説明したように、ジョブｎがジョブ１
と並行して起動している場合には、ジョブ管理モニタ１
００からジョブの種別が通知されジョブｎ用のジョブ管
理テーブル１４ｎを作成、管理することになり、複数の
起動ジョブを管理することができる。

【００５０】次に、コンピュータシステムのハードディ
スク等に何らかの障害が発生し、ジョブｎの継続ができ
ない場合の処理について説明する。

【００５１】前述に説明したように、前記ジョブ管理テ
ーブル１４０はジョブｎのステップごとにデータベース
モニタの静止点が確立された時点の情報が格納されてい
る。ジョブｎのステップｎの処理中でも同様にデータベ
ースモニタ０２０からの静止点確立の通知によって情報
が格納されていることがわかる。よってジョブｎのステ
ップｎの時点で何らかの障害がシステムに発生した場
合、障害の発生前に確立した静止点の情報をジョブｎの
ジョブ管理テーブル１４ｎに格納していることになる。

【００５２】コンピュータシステムに生じた何らかの障
害の原因を取り除いた後、前記ジョブ管理テーブル１４
ｎを参照することによって、ジョブｎの障害発生前の情
報を得ることができる。

【００５３】オペレータによって、ジョブ再起動手段１
３０を起動すると、前記ジョブ再起動手段は管理テーブ
ルデータ入出力手段１２０にジョブの再起動を行なう通
知を出す。

【００５４】前記ジョブの再起動通知を受けた管理用テ
ーブルデータ入出力手段１２０はジョブ管理テーブル１
４０の検索処理を開始する。

【００５５】ジョブ管理テーブル１４０内のステップ管
理テーブル内の処理フラグ１４１５を確認し、処理フラ
グ１４１５が処理終了を示す値であれば次のステップ管
理テーブル１４２〜１４ｎを確認する。ステップｎのス
テップ管理テーブル１４ｎの処理フラグ１４１５が処理
実行中を示す値であれば、ステップｎで処理が中断した
ことをジョブ再起動手段１３０に送信する。また、ステ
ップｎのステップ管理テーブル１４ｎ内のファイルレコ
ードポイント１４１３を参照し、入力ファイルＡ０１
１、マスタファイルＢ０１２、出力ファイルＣ０１３の
各レコードポインタ０３０をジョブ再起動手段１３０に
送信する。また、ステップ管理テーブル内の作業領域デ
ータ１４１４も同様にジョブ再起動手段１３０に送信す
る。

【００５６】前記レコードポインタ０３０と作業領域デ
ータ１４１４を受けたジョブ再起動手段１３０はジョブ
ｎの起動を行い、入力ファイルＡ０１１とマスタファイ
ルＢ０１２と出力ファイルＣ０１３の各レコードポイン
タ０３０を前記管理用テーブルデータ入出力手段１２０
から得た、レコードポインタ０３０に更新し、さらに作
業領域のデータ１４１４を前記管理用テーブルデータ入
出力手段１２０から得た作業領域データに更新する。

【００５７】ジョブ再起動手段は前記各種ファイルのレ
コードポインタ０３０と作業領域データ１４１４の更新
が済んだ後、ジョブｎのステップｎからジョブｎを再起
動することによって、障害が発生した直後から処理を継
続することができる。

【００５８】［第２実施形態］従来、情報システムの中
心を成すデータベースの管理基準ではユーザアプリケー
ション（ＡＰ）とデータベースとのトランザクションに
おける保証に止まり、障害時に処理中であったジョブへ
の保証は従来オペレータに委ねられていた。データベー
スに対してアクセスするバッチジョブＡＰにおいて処理
中に静止点を確立するロジックがある場合等、二重更新
しないよう更新済のデータを削除した入力トランザクシ
ョンを用意しなければならなかった。オペレータとして
は単純にジョブ又はステップに対する再起動（リラン）
ができないため、システム障害発生直前の状態に戻した
後も、リスタートへの作業がオペレータにとって繁雑と
なっている。

【００５９】従って、システム障害時、復旧処理の迅速
化・システムリスタートの簡便化による、安定た運用が
図れるシステムが望まれていることに鑑み、本実施形態
では、ジョブ管理ツールは処理中のデータベース又はフ
ァイルに対するレコードのポインタ情報及びジョブのワ
ークエリアのデータ情報をテーブル化し、ステップ毎に
動的に保持することとした。そうして、各ジョブはデー
タベースの静止点確立時に当テーブルに出力し、ステッ
プ処理終了後テーブルに終了フラグを出力する。当ジョ
ブ管理ツールは処理中である全ジョブに対してモニター
する。

【００６０】かかる運用によって、システム障害発生
時、オペレータは障害原因を究明した後、データベース
等を障害直前に復旧し、当ジョブ管理ツールによるリラ
ンを指示することのみによりシステムのリスタートが実
行可能となる。

【００６１】以下、図面を参照しつつ説明する。図３に
示すように、本ジョブ管理ツールは、ジョブ管理モニタ
１４０と、管理用テーブル２００と、データベース情報
取得手段１５０と、管理用テーブルデータ出力手段１６
０と、ジョブ再起動手段１７０より構成する。ジョブ管
理モニタ１４０はシステム稼働中のジョブの進行状況を
管理し、各ジョブはジョブステップの進捗状況により各
管理用テーブル２００を生成する。管理用テーブル２０
０には該当ステップのＡＰの作業領域データ及び各アサ
インファイルのレコードポインタ情報、ジョブＩＤ、ス
テップＩＤ情報をもち、データベース情報取得手段１５
０によりデータベースが静止点確立した時点を受けと
り、管理用テーブル２００に管理用テーブルデータ出力
手段１６０により出力する。この際、図４に示すよう
に、データベースモニタからデータベースの静止点確立
時の通知を受け、データベース情報取得手段１５０によ
り静止点情報を取得し、ジョブ管理モニタ１４０に通知
し、管理用テーブルデータ出力手段１６０により管理用
テーブル２００内のステップテーブルのファイルレコー
ドポインタや作業領域データの内容を更新する。

【００６２】また、処理中の当データ群はジョブ終了時
にクリアされる。つまり本ジョブ管理ツールは、処理が
実行中のジョブについて、モニターし、システム障害時
オペレータは、障害原因の調査、その後障害発生直前の
状態に復旧し、ジョブ再起動手段１７０の実行により、
各ジョブを再起動させる。当ツールの管理方法により瞬
時に障害発生直前の状態を作成することが可能になり、
従来二重更新のない入力トランザクションを生成し、実
行していた作業、又は、障害時処理中であったＡＰの再
起動作業の作業フェーズがなくなり、大幅にオペレータ
に対してシステムのリラン作業を軽減可能となる。この
障害発生時点から再起動に至る流れを要約すれば、図５
に示す手順を踏むことになる。図５において、まずシス
テム中で障害が発生したとき（Ｃ１）、オペレータは障
害の内容を調査し（Ｃ２）、データベースやその他の周
辺機器を復旧し（Ｃ３）、次に、データベースの静止点
確立時点ごとに更新しているジョブ管理テーブルから実
行ジョブ群を更新し、ジョブ管理ツールの再起動手段に
よりシステムを起動し（Ｃ４）、システムの再スタート
（リスタート）を行う。従来例と比較すれば、Ｃ４のス
テップ前にシステムの実行環境を調査して再起動の環境
設定を行うステップが不要となる。

【００６３】本実施形態では、第１実施形態で説明した
内容と比べて必要な機能について集中的に説明してい
る。また、本実施形態では、データベースモニタにより
データベースの静止点確立時点を検出して静止点確立時
点ごとにジョブ管理テーブルの起動に必要な情報を更新
する例を示したが、データベースはシステム外のＬＵＮ
等から入手する場合でも適用できるし、またデータベー
スを用いないジョブの場合であれば、他の指標を用いて
ジョブ管理テーブル内の情報を更新してもよい。

【００６４】

【発明の効果】第一の効果は、システム障害時、障害原
因を取り除いた後に、障害時のジョブ実行状況、各ジョ
ブ内のステップ処理進捗状況、また、再処理可能なファ
イルデータの調査及び作成を行なう必要が無いことであ
る。すなわち、ジョブ管理テーブルによって起動中であ
った各ジョブのステップごとの進捗状況が管理されてい
るからである。

【００６５】また、第二の効果は、使用可能環境として
通常ファイル、物理更新と論理更新が１：１または１：
ｎのデータベースシステムで使用可能である。その理由
は、ジョブ管理テーブルで複数のファイルレコードポイ
ンタの情報を格納でき、各ファイルの進捗状況に応じて
情報を管理できるからである。

【図面の簡単な説明】

【図１】本発明による実施形態の一例を示す構成図であ
る。

【図２】本発明による実施形態の一例の流れ図である。

【図３】本発明による実施形態の一例を示す構成図であ
る。

【図４】本発明による実施形態の一例の流れ図である。

【図５】本発明による実施形態の一例の流れ図である。

【符号の説明】

０１０ 起動中の各ジョブ ０１１ 入力ファイルＡ ０１２ マスタファイルＢ ０１３ 出力ファイルＣ ０２０，１８０ データベースモニタ １００，１４０ ジョブ管理モニタ １２０ 管理用テーブルデータ入出力手段 １３０，１７０ ジョブ再起動手段 １４０，２００ ジョブ管理テーブル １４１ ステップ管理テーブル １４１１ ジョブＩＤ １４１２ ステップＩＤ １４１３ ファイルレコードポインタ １４１４ 作業領域データ １４１５ 処理フラグ ａ 起動中のジョブ情報 ｂ ジョブ管理モニタと管理用テーブルデータ入
出力手段間の通知 ｃ 管理用テーブルデータ入出力手段とジョブ管
理テーブル間の通知 ｄ 起動中のジョブのデータベース使用情報 ｆ 静止点確立の通知

Claims (3)

【特許請求の範囲】
1. 【請求項１】 コンピュータシステムにおける起動中の
   ジョブが使用する入力ファイル、マスタファイル、及び
   出力ファイルと、データベースの状況を管理するデータ
   ベースモニタとを備えているジョブ管理方式において、 実行中のジョブ実行状況を監視するジョブ管理モニタ
   と、ジョブ管理情報を格納しておくジョブ管理テーブル
   と、前記データベースモニタからのジョブステップ検出
   の情報を受ける前記ジョブ管理モニタの指示により前記
   ジョブ管理テーブルの情報を受け渡しする管理用テーブ
   ルデータ入出力手段と、障害発生後に処理が中断された
   ジョブを起動するジョブ再起動手段とで構成されること
   を特徴とするジョブ管理方式。
2. 【請求項２】 コンピュータシステムにおける起動中の
   ジョブを複数のファイルとして管理するジョブ管理モニ
   タと、データベースの状況を管理するデータベースモニ
   タとを備えているジョブ管理方法において、 前記コンピュータシステムで前記データベースとデータ
   のやり取りを行う所定回数を前記データベースモニタが
   カウントし、前記所定回数のカウント毎に前記ジョブ管
   理モニタに通知し、前記ジョブ管理モニタがその通知毎
   にジョブ管理用のジョブ管理テーブル内のジョブ実行中
   のファイル状況を示すファイルポインタとジョブ作業の
   領域を示す作業領域データとを更新し、 前記コンピュータシステムで障害が発生したときに、前
   記ジョブ管理モニタは前記ファイルポインタ及び前記作
   業領域データとを前記複数のファイルに収納して再起動
   を行うことを特徴とするジョブ管理方法。
3. 【請求項３】 請求項１又は２に記載のジョブ管理方法
   において、前記ジョブ管理テーブルはジョブＩＤとジョ
   ブステップを示すステップＩＤと作業の開始・終了を示
   す処理フラグを備えたことを特徴とするジョブ管理方
   法。