JPH10289140A - バッチ処理障害時の復旧方式 - Google Patents

Abstract

(57)【要約】 【課題】入力ファイルとして磁気テープ装置等の順編成
ファイルを使用するバッチ処理では、適性に入力された
ファイルが大量にあると処理済レコードの読み飛ばしが
多く発生し再入力に時間がかかった。また、バッチ処理
が中断すると、中断原因を対策しない限り、再開始を行
っても繰り返し中断となる。さらに、分散コンピュータ
システムではその再開始方式が複雑となる。 【解決手段】本発明は、各ノードへ入力したレコードの
入力順番の一連番号を、バッチ処理中断時の再開始ポイ
ントとして管理ファイルに上書きで格納する。処理をス
キップしたレコードについては再入力ファイルに蓄積す
る。さらに、バッチ処理中断後の再開始時、スキップレ
コードの一連番号を蓄積ファイルに追加書きで格納す
る。中断原因となったレコードを含むブロック内のレコ
ードはスキップレコードとし、次のブロックレコードか
ら処理を行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータシス
テムにおけるバッチ処理障害時の復旧処理に関する。

【０００２】

【従来の技術】従来の方式では、特開平１−２７０１２
２号の記載のようにデータの品番と１対１対応でそのデ
ータが未処理か処理済であるかを示すフラグを有する管
理レコードをレコードキー対応に設け、データ処理中断
後の再開始時には対応する管理レコード内のフラグを参
照し、未処理のデータからアクセスするようにしてい
た。また、特開平３−９１０５４号の記載のように処理
済となったデータ件数を更新していくことにより、処理
途中で障害となり中断した後の再開始処理において、中
断後から再開始していた。

【０００３】

【発明が解決しようとする課題】従来技術特開平１−２
７０１２２号では、あらかじめ入力データのレコードキ
ー対応に管理レコードを作成しておかなくてはならな
い。また、従来技術特開平３−９１０５４号は入力にＤ
Ｂを用い、かつ、あらかじめＤＢ構造に対応した入力Ｄ
Ｂ管理テーブルを作成しておかなくてはならない。この
ため、バッチ入力ファイルとして一般的な磁気テープ装
置等の順編成ファイルには適用できない欠点がある。ま
た、従来技術特開平３−９１０５４号は中断原因レコー
ドの次のレコードから再開始を行うことができるが、レ
コードを順次処理するのが原則であり、ブロック内のレ
コードを並行に処理したときのブロック単位のスキップ
はできていない。さらに、特開平１−２７０１２２号、
特開平３−９１０５４号とも分散コンピュータシステム
における処理方式が提示されていない。

【０００４】

【課題を解決するための手段】本発明ではバッチ処理ご
と、かつノードごと管理ファイルと蓄積ファイルを持
つ。ある入力レコードが正常に処理完了した場合、この
レコードのノード別入力一連番号をバッチ処理中断時の
再開始ポイントとして管理ファイルに上書きで格納す
る。

【０００５】また、レコード不正、タイミングエラー等
で処理をスキップしたレコードについては、別の再入力
ファイルに蓄積し、バッチ終了後の再入力に備えるとと
もに、バッチ中断後の再開始時、入力ファイルから前回
のスキップレコードを抽出し、再入力ファイルを再構築
するため、スキップレコードのノード別入力一連番号を
蓄積ファイルに追加書きで格納する。

【０００６】一方、バッチ異常終了後の再開始では、管
理ファイルから処理済レコードの最終一連番号を取得
し、蓄積ファイルからスキップレコードの一連番号を取
得する。これらの情報をもとに入力ファイル読み込み
時、処理済レコードは読み飛ばし、スキップレコードは
再入力ファイルに書き出す。また、処理済の最終一連番
号以降で中断原因となったレコードを含むブロック内の
レコードは再度の中断を避けるため、スキップレコード
として扱い、次のブロックレコードから処理を行う。以
上のように、バッチが異常終了しても、再開始を行い入
力ファイルを最後まで処理する。

【０００７】その後、異常終了原因、スキップ原因を対
策してから再入力ファイルを入力してレコード全件の処
理を完了する。

【０００８】

【発明の実施の形態】次に本発明について図面を参照し
て説明する。図１は本発明の一実施例を示す図であり、
データの処理の流れに沿って処理方式の概略を示したも
のである。本システムは補助記憶装置である入力ファイ
ル１０１、管理ファイル１０９、蓄積ファイル１１０、
再入力ファイル１１１、プログラムであるクライアント
１０２、管理サーバ１０５、ユーザサーバ１０７から成
り立っている。図２は管理ファイル１０９、蓄積ファイ
ル１１０の詳細図であり、管理ファイル１０９はバッチ
処理ごとの管理レコードヘッダと並行処理するブロック
内レコード数分の管理レコードからなり、蓄積ファイル
１１０はスキップレコード対応の蓄積レコードからな
る。

【０００９】図３はクライアント処理、図４は管理サー
バ処理、図５はユーザサーバの処理例の手順を示したフ
ローチャートである。

【００１０】先ず、図１、図３をもとにクライアント処
理（３０１）の流れを説明する。クライアント１０２が
全ノードの管理ファイル１０９と蓄積ファイル１１０を
管理サーバ１０５経由で読み込む（３０２）。ノードご
との管理レコードヘッダ内の再開始モードフラグ２０３
の１つでも再開始モードかを判定する（３０３）。ＹＥ
Ｓであれば処理（３０５）を行なう。ＮＯであれば、全
ノードの管理ファイル１０９と蓄積ファイル１１０を初
期化する（３０４）。

【００１１】入力ファイル１０１と再入力ファイル１１
１をオープンする（３０５）。入力ファイル１０１から
入力レコードを入力バッファ１０３に読み込む（３０
６）。入力ファイル１０１がＥＯＦか判定する（３０
７）。ＹＥＳであれば、全ノードの管理ファイル中の再
開始モードフラグをクリアし（３２０）、処理（３２
１）を行う。ＮＯであれば、入力バッファから１レコー
ドを取り出す（３０８）。入力バッファがＥＯＦである
かを判定する（３０９）。ＹＥＳあれば処理（３０６）
へ戻る。ＮＯであれば、当該レコードのノード別一連番
号を求める（３１０）。再開始モードで、かつ、このレ
コードが前回スキップレコードであるかをスキップレコ
ード一連番号２１１と比較して判定する（３１１）。Ｙ
ＥＳであれば処理（３１８）を行う。ＮＯであれば、再
開始でノード内処理済一連番号２０４以下のレコードか
を判定する（３１２）。ＹＥＳであれば処理（３０８）
へ戻る。ＮＯであれば当該レコードをノード別に送信バ
ッファ１０４にバッファリングする（３１３）。管理サ
ーバ１０５側が処理待ち、又は送信バッファ１０４が満
杯の状態かを判定する（３１４）。ＹＥＳであれば管理
サーバ１０５に送信する（３１５）。ＮＯであれば処理
（３０８）へ戻る。管理サーバ１０５からリターンした
ならば、バッチ停止要求有りかを判定する（３１６）。
ＹＥＳであれば、処理（３２１）を行う。ＮＯであれ
ば、スキップレコード有りかの判定を行う（３１７）。
ＮＯであれば、当該送信バッファの全レコードは処理正
常であり、次のレコード処理（３０６）へ戻る。ＹＥＳ
であれば、応答されたスキップレコードの一連番号から
送信バッファ１０４中のスキップレコードを求め、再入
力ファイル１１１に書き出す（３１８）。再入力ファイ
ルへの書き出しでＩ／Ｏエラーが発生したか判定を行う
（３１９）。ＹＥＳであれば、処理（３２１）を行う。
ＮＯであれば、次のレコード処理（３０８）へ戻る。入
力ファイル、再入力ファイルのクローズ処理を行い（３
２１）、さらに、その他のバッチ終了処理を行い（３２
２）、バッチを終了する（３２３）。

【００１２】次に、図１、図４をもとに管理サーバ処理
（４０１）の流れを説明する。管理サーバ１０５は受信
バッファ１０６をデブロッキングする（４０２）。ブロ
ック内先頭レコードをキャッチする（４０３）。再開始
でかつ当該レコードの一連番号は管理レコードヘッダの
ノード内グレーレコード終端一連番号２０４以下かの判
定を行う（４０４）。ＹＥＳであれば、当該レコードの
一連番号は管理レコードの個別処理済一連番号２０８と
等しいかの判定を行う（４１４）。処理（４１４）でＹ
ＥＳの場合、前回のバッチ実行で処理完了したレコード
として処理（４１７）を行う。処理（４１４）でＮＯの
場合、前回のバッチ実行で中断原因のある処理未完のレ
コードとして当該レコードの一連番号をスキップレコー
ド一連番号２１１に登録し、蓄積ファイル１１０へ追加
する。（４１５）。さらにスキップレコード番号を応答
エリアにセットする（４１６）。ブロック内全レコード
処理済かの判定を行う（４１７）。ＹＥＳであれば、ク
ライアントヘリターンする（４２６）。ＮＯであれば、
処理（４０４）へ戻る。処理（４０４）でＮＯであれば
ブロック内終端一連番号を管理レコードヘッダのノード
内グレーレコード終端一連番号２０５として更新し、再
開始モードフラグ２０３をセットする（４０５）。受信
バッファ中の全未処理レコードを並行にユーザサーバへ
送信する（４０６）。ユーザサーバからあるレコードに
ついての応答が返されたならば、ユーザサーバタイムオ
ーバであるか、又は、バッチ停止応答かを判定する（４
０７）。ＹＥＳであれば、ユーザ処理をロールバックし
（４１９）、バッチ停止要求コードを応答エリアにセッ
トし（４２０）、処理（４１２）を行う。ＮＯであれ
ば、管理レコードの個別処理済一連番号２０８を更新す
る（４０８）。当該レコードについてスキップ応答され
たか判定する（４０９）。ＹＥＳであれば、ユーザ処理
をロールバックし（４２１）、スキップレコード一連番
号２１１に当該レコードの一連番号を登録し、蓄積ファ
イル１１０に追加する（４２２）。さらに、スキップレ
コード番号を応答エリアにセットし（４２３）、処理
（４１２）を行う。ＮＯであれば、ユーザ処理をコミッ
トし（４１０）、処理正常コードを応答エリアにセット
する（４１１）。その後、ブロック内全レコード処理済
かの判定を行う（４１２）。ＮＯであれば、他のレコー
ドのユーザサーバ処理応答を待ち（４１３）、応答され
たら処理（４０７）へ戻る。ＹＥＳであれば、管理レコ
ードヘッダのグレーレコード終端一連番号２０５をノー
ド内処理済一連番号２０４にセットし（４２４）、クラ
イアントヘリターンする（４２５）。

【００１３】次に、図１、図５をもとにユーザサーバ処
理例（５０１）の流れを説明する。先ず、処理レコード
１０８のチェックを行い（５０２）、入力不正かの判定
を行う（５０３）。

【００１４】ＹＥＳであれば、スキップ応答（５０９）
を行い、管理サーバヘリターンする（５１０）。ＮＯで
あれば、データベースアクセスを伴うユーザ処理を実行
する（５０４）。その後、ユーザ処理エラーかの判定を
行い（５０５）、ＹＥＳであれば、バッチ処理続行不可
かの判定を行う（５０７）。さらに、ＹＥＳであれば、
バッチ停止応答を行い（５０８）、管理サーバヘリター
ンする（５１０）。処理（５０７）でＮＯであれば、ス
キップ応答（５０９）を行い、管理サーバヘリターンす
る（５１０）。

【００１５】処理（５０５）でＮＯであれば、正常応答
を行い（５０６）、管理サーバヘリターンする（５１
０）。

【００１６】

【発明の効果】以上説明したように、本発明ではバッチ
入力ファイルとして一般的な磁気テープ装置等の順編成
ファイルを扱うことができ、中断原因を対策せずに、再
開始を行っても繰り返しの中断とならない。さらに、分
散コンピュータシステムにおいても適用ができる効果が
ある。

【図面の簡単な説明】

【図１】本発明によるバッチ処理システムの構成例を示
す図である。

【図２】本発明によるバッチ処理システムが使用する作
業用ファイルの詳細図である。

【図３】本発明によるバッチ処理システムを構成するク
ライアント処理の手順を示したフローチャートである。

【図４】本発明によるバッチ処理システムを構成する管
理サーバ処理の手順を示したフローチャートである。

【図５】本発明によるバッチ処理システムを構成するユ
ーザサーバの処理例の手順を示したフローチャートであ
る。

【符号の説明】

１０１…入力ファイル、１０２…クライアント、１０３
…入力バッファ、１０４…送信バッファ、１０５…管理
サーバ、 １０６…受信バッファ、１０７…ユーザサー
バ、１０８…処理レコード、１０９…管理ファイル、１
１０…蓄積ファイル、１１１…再入力ファイル。

Claims (3)

【特許請求の範囲】
1. 【請求項１】バッチ処理において、入力レコード不正、
   またはタイミングエラー等で入力レコードが処理できな
   い場合、処理をスキップし、当該レコードを入力ファイ
   ルとは別のファイルに蓄積しつつ処理を進め、バッチ処
   理を終了させた後、スキップレコードを蓄積したファイ
   ルを再入力することによりレコード全件を処理完了とす
   る方式。
2. 【請求項２】バッチ処理において、プログラム不正等で
   バッチ処理が中断した場合、再開始時、処理完了となっ
   たレコードは読み飛ばし、繰り返しの中断を避けるた
   め、中断原因レコードを含むブロックの次のブロックか
   ら再開始を行い、中断原因レコードを含むブロック内の
   処理未完となったレコードは再入力に備えてスキップレ
   コードとして別のファイルに蓄積する方式。
3. 【請求項３】分散コンピュータシステムのバッチ処理に
   おいて、各ノードに管理ファイルと蓄積ファイルを持
   ち、各ノードごとに入力レコードの再開始位置、および
   スキップレコードの位置を入力レコードのノード別一連
   番号の形式で保持することにより、バッチ処理が繰り返
   しの中断となっても再開始を繰り返し行うことにより、
   同一レコードの処理重複、およびレコードの処理抜けを
   防止してレコード全件を処理完了とする方式。