JP2009217587A - バッチ処理装置及び方法 - Google Patents

Abstract

【課題】障害が発生したときのバッチジョブ運用を省力化し得るバッチ処理装置及び方法を提案する。
【解決手段】所定の資源を利用するバッチ処理を実行するバッチ処理装置及び方法において、バッチ処理のうちの次に実行するジョブが利用する資源を特定すると共に、当該資源に障害が発生しているか否かを判定し、当該資源に障害が発生していると判定したときには、当該障害に関する障害情報をユーザに提示し、ユーザからの応答を得るまで当該ジョブの実行を延期するようにした。
【選択図】図１１

Description

本発明は、バッチ処理装置及び方法に関し、例えばストレージ装置内の資源を利用するバッチ処理を実行する計算機に適用して好適なものである。

データを一定期間あるいは一定量まとめてから一括して処理を行うバッチ処理システムにおいて、バッチ処理の単位であるジョブ内でアプリケーションプログラムが使用（入出力）するファイルを記述したジョブ定義ファイルを解釈実行するバッチ処理システムが例えば、下記特許文献１に開示されている。また、下記特許文献２には、同じ故障要因で故障し、その故障要因が復旧された複数のジョブに対して一括して動作を再開させる技術が開示されている。

従来のバッチ処理システムでは、ジョブで使用するファイルが格納されたストレージ装置内の論理ボリューム（以下、これを単にボリュームと呼ぶ）や、ボリュームとアプリケーションプログラムが動作している計算機間のパス（通信路）に障害が発生した場合においても、事前にスケジュールされたジョブは実行されていた。

しかしながら、かかるジョブが障害が発生した論理ボリュームに格納されているファイルを使用する場合、そのジョブは異常終了する。このためユーザは、異常終了の要因がボリュームやパスの障害であることを、ジョブ出力結果や障害ログなどから判別し、障害回復後にジョブを再スケジュールする必要があった。
特開２００７−４１７２０号公報 特開２００５−２２２１０５号公報

上述のように従来のバッチ処理システムでは、障害が発生した場合であっても事前にスケジュールされたジョブが実行され、障害ボリュームに格納されたファイルを使用しようとした時点で当該ジョブが異常終了してしまう。このため、ユーザは、いちいち異常終了要因を特定し、異常個所を修復するなどの処理を行なった後に、ジョブを再スケジュールしなければならず、ユーザに余分な作業を強いる問題があった。

本発明は以上の点を考慮してなされたもので、障害が発生したときのバッチジョブ運用を省力化し得るバッチ処理装置及び方法を提案しようとするものである。

かかる課題を解決するため本発明においては、バッチ処理のうちの次に実行するジョブが利用する資源に障害が発生しているか否かを判定し、障害が発生していると判定したときには、当該障害に関する障害情報をユーザに提示し、ユーザからの応答を得るまで当該ジョブの実行を延期するようにした。

すなわち本発明においては、バッチ処理装置において、プログラムが格納された主記憶装置と、前記主記憶装置に格納された前記プログラムに従って所定の資源を利用するバッチ処理を実行するプロセッサとを備え、前記プロセッサは、前記バッチ処理のうちの次に実行するジョブが利用する前記資源を特定すると共に、当該資源に障害が発生しているか否かを判定し、当該資源に障害が発生していると判定したときには、当該障害に関する障害情報をユーザに提示し、ユーザからの応答を得るまで当該ジョブの実行を延期することを特徴とする。

また本発明においては、所定の資源を利用するバッチ処理を実行するバッチ処理方法において、前記バッチ処理のうちの次に実行するジョブが利用する前記資源を特定すると共に、当該資源に障害が発生しているか否かを判定する第１のステップと、当該資源に障害が発生していると判定したときには、当該障害に関する障害情報をユーザに提示し、ユーザからの応答を得るまで当該ジョブの実行を延期する第２のステップとを備えることを特徴とする。

さらに本発明においては、プログラムにおいて、所定の資源を利用するバッチ処理を実行するバッチ処理のうちの次に実行するジョブが利用する前記資源を特定すると共に、当該資源に障害が発生しているか否かを判定する第１のステップと、当該資源に障害が発生していると判定したときには、当該障害に関する障害情報をユーザに提示し、ユーザからの応答を得るまで当該ジョブの実行を延期する第２のステップとを備えることを特徴とする処理をコンピュータに実行させるようにした。

本発明によれば、スケジュールされたジョブが利用する資源に対する資源の障害情報をユーザに提示し、応答を求めるため、これらの情報を元にジョブが実行される前に対象を絞り込んで障害の有無を確認することが可能となるであり、ストレージに障害が発生したときのバッチジョブ運用を省力化することができる。

以下図面について、本発明の一実施の形態を詳述する。

（１）本実施の形態による計算機システムの構成
図１において、１は全体として本実施の形態による計算機システムを示す。この計算機システム１は、バッチ処理を実行する計算機２と、計算機２に対して記憶領域を提供するストレージ装置３とを備えて構成される。計算機２及びストレージ装置３は、例えばＳＡＮ（Storage Area Network）、ＬＡＮ(Local Area Network)、ＷＡＮ（Wide Area Network）、インターネット、専用回線又は公衆回線などからなる通信ネットワーク４を介して接続されている。

計算機２は、主記憶装置１０、ＣＰＵ（Central Processing Unit）１１及び入出力インターフェース１２を備える。主記憶装置１０は、半導体メモリ等で構成される。そしてこの主記憶装置１０には、ジョブ管理プログラム２０、ストレージ管理プログラム２１及びオペレーティングシステム２２などの命令コードと、これらジョブ管理プログラム２０、ストレージ管理プログラム２１及びオペレーティングシステム２２が参照する各種テーブル２３〜２８とが格納される。

ＣＰＵ１１は、計算機２全体の動作制御を司るプロセッサであり、主記憶装置１０に格納されたジョブ管理プログラム２０、ストレージ管理プログラム２１及びオペレーティングシステム２２の命令コードをロードして解釈実行する。なお、以下においては、各種処理の処理主体を「プログラム」として説明するが、実際上は、そのプログラムに基づいてＣＰＵ１１がその処理を実行することは、言うまでもない。

入出力インターフェース１２は、通信ネットワーク４を介してストレージ装置３にアクセスするためのインターフェースであり、例えばホストバスアダプタから構成される。

計算機２には、計算機２内のプログラムからのメッセージを表示し、メッセージに対するユーザの応答を受け付けて計算機２に転送するコンソール５が接続される。コンソール５は、例えばパーソナルコンピュータから構成される。

ストレージ装置３は、ストレージ部３０及びコントローラ部３１から構成される。ストレージ部３０は、それぞれ物理的な記憶領域を提供する１又は複数のディスクドライブを備える。１又は複数のディスクドライブが提供する記憶領域上に１又は複数の論理的なボリュームＶＯＬが定義される。そしてユーザにより作成されたジョブ定義ファイル３２や、計算機２上のアプリケーションプログラムが使用するファイル３３などがこのボリュームＶＯＬに格納される。またコントローラ部３１は、計算機２からの入出力要求に応じて、ストレージ部３０に対するジョブ定義ファイル３２やプログラムが使用するファイル３３の入出力制御を行う。

なお、本計算機システム１の場合、計算機２やストレージ装置３に搭載されたコピー機能により、計算機２がファイル３２を読み書きするボリュームＶＯＬの複製をストレージ装置３内に作成することができる。この場合、コピー元のボリュームＶＯＬの更新内容は、同期又は非同期にコピー先のボリュームＶＯＬに差分反映され、これによりコピー元のボリュームＶＯＬ及びコピー先のボリュームＶＯＬの内容が常に同一の状態に維持される。以下においては、コピー元のボリュームＶＯＬを正ボリュームＰＶＯＬ、コピー先のボリュームＶＯＬを副ボリュームＶＯＬと呼び、正ボリュームＰＶＯＬ及びその副ボリュームＶＯＬの組をボリュームペアと呼ぶものとする。

図２は、ジョブ定義ファイル３２の記述例を示す。ジョブ定義ファイル３２は、計算機２上のアプリケーションプログラムが実行するジョブの内容を規定したファイルであり、例えば計算機２を用いてユーザにより予め作成され、ストレージ装置３内の所定のボリュームＶＯＬに格納される。

図２において、先頭行はジョブ定義文を表す。「JOB ID=」に続く「JOBa」はジョブを一意に識別するジョブＩＤを示す。２行目は、そのジョブを実行するアプリケーションプログラムが使用するファイル３３のファイル定義文を表す。「DD NAME=」に続く「FILE1」が、そのファイル３３を識別するためのファイル識別名を示し、「FILE=」に続く「/dirA/file1」がファイル３３のパス名を示す。このファイル定義文における「DELETE=YES」は、ジョブ終了後にそのファイル３３を削除することを表す。また図２には表記されていないが、ジョブ定義ファイル２１には、そのジョブを実行すべき計算機２上のアプリケーションプログラムの識別情報等も記述される。

（２）計算機におけるバッチ処理機能
次に、かかる計算機システム１の計算機２に搭載された障害対処機能について説明する。本実施の形態による計算機２には、ストレージ装置３の所定ボリュームＶＯＬに格納された複数のジョブ定義ファイル３２に従って、各ジョブ定義ファイル３２においてそれぞれ定義されたジョブを順次連続して実行するバッチ処理機能が搭載されている。

この場合において、計算機２は、バッチ処理時、ジョブを実行する前に、当該ジョブが使用するボリュームＶＯＬや当該ボリュームＶＯＬ及び計算機２間のパスに障害又は障害発生のおそれがあるか否かをチェックし、障害又は障害発生のおそれがあるときには、ユーザからの許可があるまで当該ジョブの実行を延期する点を特徴の１つとしている。

このようなバッチ処理を実行するための手段として、計算機２の主記憶装置１０には、ジョブファイル管理テーブル２３、ジョブボリューム管理テーブル２４、ボリュームペア管理テーブル２５、ボリューム管理テーブル２６、ボリュームパス管理テーブル２７及びパス管理テーブル２８が格納されている。

ジョブファイル管理テーブル２３は、ジョブ定義ファイル３２に定義されたジョブをジョブ管理プログラム２０が管理するためのテーブルであり、図３に示すように、パス名欄２３Ａ、ボリュームＩＤ欄２３Ｂ、ジョブＩＤ欄２３Ｃ、ファイル識別名欄２３Ｄ及び削除対象情報欄２３Ｅから構成される。

そしてジョブＩＤ欄２３Ｃには、ジョブ定義ファイル３２において定義されたジョブの識別子（以下、これをジョブＩＤと呼ぶ）が格納され、ファイル識別名欄２３Ｄには、そのジョブで使用するファイル３３の識別子（以下、これをファイル識別名と呼ぶ）が格納される。

またパス名欄２３Ａには、計算機２からかかるファイル３３へのパスのパス名が格納され、ボリュームＩＤ欄２３Ｂには、そのファイル３３が格納されたストレージ装置３内のボリュームＶＯＬの識別子（以下、これをボリュームＩＤと呼ぶ）が格納される。ボリュームＩＤとしては、例えば「hda」などのデバイス名や、４桁１６進数のデバイスＩＤが適用される。

さらに削除対象情報欄２３Ｅには、対応するジョブの終了後に当該ジョブで使用したファイル３３を削除するか否かを判別するための情報（以下、これを削除対象情報と呼ぶ）が格納される。例えばファイル定義文において、「DELETE=YES」との記述がある場合には、「ＹＥＳ」という削除対象情報が削除対象情報欄に格納される。また削除対象情報欄２３Ｅには、対応するジョブの終了時にボリューム異常などの要因により削除できなかった場合に、「ＦＡＩＬＥＤ」という削除対象情報が格納される。これ以外の場合には、削除対象情報欄２３Ｅに削除対象情報は格納されない。

またジョブボリューム管理テーブル２４は、バッチ処理のジョブが利用するボリュームＶＯＬをジョブ管理プログラム２０が管理するためのテーブルであり、図４に示すように、ボリュームＩＤ欄２４Ａ、マウントポイントパス欄２４Ｂ、チェック要因情報欄２４Ｃ、障害フラグ欄２４Ｄ及び副ボリューム欄２４Ｅから構成される。

そしてボリュームＩＤ欄２４Ａには、ジョブファイル管理テーブル２３にボリュームＩＤが登録された各ボリュームＶＯＬの当該ボリュームＩＤがそれぞれ格納される。またマウントポイントパス欄２４Ｂには、対応するボリュームＶＯＬがマウントされたディレクトリ（マウントポイント）のパス名が格納される。マウントポイントパス欄２４Ｂに格納されたパス名にボリュームＶＯＬ内のパス名を連結した文字列がファイル３３のパス名となる。

チェック要因情報欄２４Ｃには、対応するボリュームＶＯＬを利用したジョブが異常終了したときに、そのジョブのジョブＩＤが格納される。また障害フラグ欄２４Ｄには、対応するボリュームＶＯＬに障害が発生しているか否かを表すフラグ（以下、これを障害フラグと呼ぶ）が格納される。後述のように、チェック要因情報欄２４ＣにジョブＩＤが格納されている場合、対応するボリュームＶＯＬに障害が発生しているか否かがチェックされ、このチェックの結果、当該ボリュームＶＯＬに障害が発生していることが検出された場合には障害フラグが「ＯＮ」に設定される。障害フラグが「ＯＦＦ」の場合は、対応するボリュームＶＯＬに障害が発生していないか、又は当該ボリュームＶＯＬに障害が発生しているか否かをチェックしていない状態であることを示す。

さらに副ボリュームＩＤ欄２４Ｅには、対応するボリュームＶＯＬの副ボリュームＳＶＯＬ（複製）が存在する場合に、その副ボリュームＳＶＯＬのボリュームＩＤが格納される。従って、対応するボリュームＶＯＬの副ボリュームＳＶＯＬが存在しないときには、そのエントリの副ボリュームＩＤ欄２４Ｅには何も格納されない。

一方、ボリュームペア管理テーブル２５は、ストレージ管理プログラム２１がストレージ装置３内のボリュームペアを管理するためのテーブルであり、図５に示すように、正ボリュームＩＤ欄２５Ａ及び副ボリュームＩＤ欄２５Ｂから構成される。そして正ボリュームＩＤ欄２５Ａ及び副ボリュームＩＤ欄２５Ｂには、ストレージ装置４内に設定された各ボリュームペアの正ボリュームＰＶＯＬ又は副ボリュームＳＶＯＬのボリュームＩＤがそれぞれ格納される。

またボリューム管理テーブル２６は、ストレージ管理プログラム２１がボリュームＶＯＬの障害を管理するためのテーブルであり、図６に示すように、ボリュームＩＤ欄２６Ａ及び障害フラグ欄２６Ｂから構成される。そしてボリュームＩＤ欄２６Ａには、ストレージ装置３内に設定された各ボリュームＶＯＬのボリュームＩＤがそれぞれ格納され、障害フラグ欄２６Ｂには、対応するボリュームＶＯＬに障害が発生しているか否かを表すボリューム障害フラグが格納される。この場合、ボリューム障害フラグは、対応するボリュームＶＯＬに障害が生じている場合には「ＯＮ」、当該ボリュームＶＯＬに障害が生じていない場合には「ＯＦＦ」に設定される。

ボリュームパス管理テーブル２７は、計算機２から各ボリュームＶＯＬへのパスをストレージ管理プログラム２１が管理するためのテーブルであり、図７に示すように、ボリュームＩＤ欄２７Ａ及びパスＩＤ欄２７Ｂから構成される。そしてボリュームＩＤ欄２７Ａには、対応するボリュームＶＯＬのボリュームＩＤが格納され、パスＩＤ欄２７Ｂには、そのボリュームＶＯＬへのパスのパスＩＤが格納される。パスＩＤは、例えば計算機２の入出力インターフェース１２（図１）の識別子と、ストレージ装置３の受信ポートの識別子とを組み合わせて生成される。

さらにパス管理テーブル２８は、計算機２及びボリュームＶＯＬ間のパス障害をストレージ管理プログラム２１が管理するためのテーブルであり、図８に示すように、パスＩＤ欄２８Ａ及び障害フラグ欄２８Ｂから構成される。そしてパスＩＤ欄２８Ａには、対応するパスのパスＩＤが格納され、障害フラグ欄２８Ｂには、そのパスに障害が発生しているか否かを表すパス障害フラグが格納される。パス障害フラグは、対応するパスに障害が生じているときには「ＯＮ」、障害が生じていないときには「ＯＦＦ」が設定される。

図９は、ジョブ管理プログラム２０によるジョブ実行処理の処理手順を示している。ジョブ管理プログラム２０は、バッチ処理時、まず、次に実行しようとするジョブのジョブ定義ファイル３２をストレージ装置３から読み出す。そしてジョブ管理プログラム２０は、読み出したジョブ定義ファイル３２を解析し、ジョブ定義文のＩＤオペランドからジョブＩＤを、ＮＡＭＥオペランドから環境変数名を、ＦＩＬＥオペランドからファイル３３のパス名を、ＤＥＬＥＴＥオペランドから削除の有無をそれぞれ抽出する。そのジョブ定義ファイル３２に複数のジョブ定義文が存在するときには、各ジョブ定義文について同様の処理を行なう（ＳＰ１）。

次いでジョブ管理プログラム２０は、そのジョブ定義ファイル３２の１つのジョブ定義文に対してジョブファイル管理テーブル２３の新規エントリを１つ割り当て、ステップＳＰ１においてそのジョブ定義ファイル３２から抽出したそのジョブ定義文に関するパス名、ジョブＩＤ及びファイルＩＤをその新規エントリのパス名欄２３Ａ、ジョブＩＤ欄２３Ｃ及びファイル識別名欄２３Ｄにそれぞれ格納する。またジョブ管理プログラム２０は、そのジョブ定義文においてＤＥＬＥＴＥオペランドが存在する場合には、「ＹＥＳ」という削除対象情報をその新規エントリの削除対象情報欄２３Ｅに格納する（ＳＰ２）。

続いてジョブ管理プログラム２０は、そのジョブで使用するファイル３３が格納されたボリュームＶＯＬのボリュームＩＤを求め、そのボリュームＩＤをジョブファイル管理テーブル２３及び必要に応じてジョブボリューム管理テーブル２４に格納する（ＳＰ３）。

具体的に、ジョブ管理プログラム２０は、例えばstat()関数を発行し、ジョブファイル管理テーブル２３におけるそのジョブに割り当てられた新規エントリのパス名欄２３Ａに格納されたパス名に対応するデバイスＩＤ（ボリュームＩＤ）を問い合わせる。あるいは、マウントされるボリュームＶＯＬのファイルシステム情報が記述されているファイル（fstab）を読み込む。そしてジョブ管理プログラム２０は、上述のようにして得られたボリュームＩＤをジョブファイル管理テーブル２３のかかる新規エントリのボリュームＩＤ欄２３Ｂに格納する。

またジョブ管理プログラム２０は、そのとき取得したボリュームＩＤがジョブボリューム管理テーブル２４に登録されていないときには、そのボリュームＩＤのボリュームＶＯＬにジョブボリューム管理テーブル２４の新規エントリを１つ割り当て、そのエントリのボリュームＩＤ欄２４Ａに当該ボリュームＩＤを格納すると共に、そのボリュームＩＤのボリュームＶＯＬがマウントされたマウントポイントまでのパス名を当該新規エントリのマウントポイントパス欄２４Ｂに格納する。

なお、ジョブ管理プログラム２０は、そのとき対象としているジョブ定義ファイル３２に複数のジョブ定義文が記述されているときには、ステップＳＰ２及びステップＳＰ３の処理をジョブ定義文ごとに実行する。

次いで、ジョブ管理プログラム２０は、そのジョブ定義ファイル３２において定義されたジョブで利用するボリュームＶＯＬ（つまり、そのジョブで使用するファイル３３が格納されたボリュームＶＯＬ）や、当該ボリュームＶＯＬ及び計算機２間のパスに障害があるか否かをチックするボリューム障害チェック処理を実行する（ＳＰ４）。このボリューム障害チェック処理の具体的な処理内容については、後述する。

続いてジョブ管理プログラム２０は、ジョブファイル管理テーブル２３のエントリのうち、そのジョブ定義ファイル３２において定義されたジョブのジョブＩＤがジョブＩＤ欄２３Ｃに格納されたすべてのエントリについて、パス名欄２３Ａに格納されたパス名を、ファイル識別名欄２３Ｄに格納されたファイル識別名（環境変数）に変更する（ＳＰ５）。

この後ジョブ管理プログラム２０は、ジョブ定義ファイル３２を参照してそのジョブを実行すべきアプリケーションプログラムを起動し、そのジョブが終了するのを待ち受ける（ＳＰ６）。そしてジョブ管理プログラム２０は、やがてそのジョブが終了すると、当該ジョブが異常終了したか否かを判断する（ＳＰ７）。そしてジョブ管理プログラム２０は、この判断において否定結果を得るとステップＳＰ１０に進む。

これに対して、かかる判断において肯定結果を得た場合、ジョブが異常終了した要因としてボリューム障害やパス障害が考えられるため、そのジョブで利用するボリュームＶＯＬや当該ボリュームＶＯＬへのパスを、次のジョブを実行する前にチェックしておく必要がある。

そこで、このときジョブ管理プログラム２０は、その異常終了したジョブで利用したボリュームＶＯＬのボリュームＩＤをジョブファイル管理テーブル２３から読み出し、ジョブボリューム管理テーブル２４のエントリのうち、そのボリュームＩＤがボリュームＩＤ欄２４Ａに格納されたエントリのチェック要因情報欄２４Ｃにそのとき異常終了したジョブのジョブＩＤを格納する（ＳＰ８）。

またジョブ管理プログラム２０は、異常終了したジョブのジョブＩＤと、当該ジョブで利用したボリュームＶＯＬのボリュームＩＤとなどを障害情報としてコンソール５（図１）に送信する（ＳＰ９）。かくしてコンソール５は、この障害情報に基づいて所定の障害通知画面を表示し、ユーザにチェックを促す。

続いてジョブ管理プログラム２０は、そのとき実行したジョブで使用したファイル３３について削除すべき設定（「DELETE=YES」）がなされているときには、そのファイル３３を削除する（ＳＰ１０，ＳＰ１１）。具体的にジョブ管理プログラム２０は、ジョブファイル管理テーブル２３のエントリのうち、そのとき実行したジョブのジョブＩＤがジョブＩＤ欄２３Ｃに格納され、かつ削除対象情報欄２３Ｅに「ＹＥＳ」が格納されたエントリがあるか否かを判断する（ＳＰ１０）。そしてジョブ管理プログラム２０は、この判断において否定結果を得るとステップＳＰ１４に進み、これに対して肯定結果を得ると、そのジョブで利用したボリュームＶＯＬから対応するファイル３３を削除する（ＳＰ１１）。

次いでジョブ管理プログラム２０は、そのとき実行したジョブが異常終了し、かつステップＳＰ１１におけるファイル３３の削除処理も失敗したか否かを判断したか否かを判断する（ＳＰ１２）。そしてジョブ管理プログラム２０は、この判断において肯定結果を得た場合には、そのファイル３３をボリューム障害の回復後に削除するため、ジョブファイル管理テーブル２３の対応するエントリの削除対象情報欄２３Ｅに格納された削除対象情報を「ＦＡＩＬＥＤ」に変更する（ＳＰ１３）。

これに対してジョブ管理プログラム２０は、ステップＳＰ１２の判断において否定結果を得た場合には、ジョブファイル管理テーブル２３のそのエントリはもはや不要であることから、当該ジョブファイル管理テーブル２３のエントリのうち、ジョブＩＤ欄２３Ｃに格納されたジョブＩＤがステップＳＰ６において実行したジョブのジョブＩＤと一致し、かつ削除対象情報欄２３Ｅに「ＦＡＩＬＥＤ」という削除対象情報が格納されていないエントリをすべて解放（ジョブファイル管理テーブル２３から削除）する（ＳＰ１４）。

そしてジョブ管理プログラム２０は、この後、そのとき対象としていたジョブ定義ファイル３２に関するジョブ実行処理を終了し、他のジョブ定義ファイル３２があるときには、すべてのジョブ定義ファイル３２について同様の処理（ＳＰ１〜ＳＰ１４）を繰り返す。

図１０に、上述のジョブ実行処理のステップＳＰ９においてジョブ管理プログラム２０からの障害情報に基づいてコンソール５が表示する障害通知画面の構成例を示す。この図１０に示す障害通知画面４０では、ジョブが異常終了した旨のメッセージと、異常終了したジョブのジョブＩＤと、当該ジョブで利用したボリュームＶＯＬのボリュームＩＤとが表示される。かくして、ユーザは、この障害通知画面４０にボリュームＩＤが表示されたボリュームＶＯＬ（図１０では「hda1」）に障害が発生しているか否かを調査し、障害が発生していると認められた場合にはＡＣＴＩＯＮ欄４０Ａに「Ｙ」、認められなかった場合には「Ｎ」を入力するようにする。そしてかかるＡＣＴＩＯＮ欄４０Ａに「Ｙ」を入力した場合、その旨が計算機２のジョブ管理プログラム２０に通知される。

なお、かかる通知を受けたジョブ管理プログラム２０が、ジョブボリューム管理テーブル２４の対応するエントリ（かかるＡＣＴＩＯＮ欄４０Ａに「Ｙ」が入力された行に記載されたボリュームＩＤがボリュームＩＤ欄２４Ａに格納されたエントリ）の障害フラグ欄２４Ｄに格納された障害フラグを「ＯＮ」に設定すると共に、当該エントリのチェック要因情報欄２４Ｃに格納されているジョブＩＤを消去するようにしても良い。

また、かかる障害通知画面４０への入力のかわりに、障害が発生したボリュームＶＯＬのボリュームＩＤをオペランドに指定したコマンドをユーザに入力させ、このコマンドに基づいてジョブ管理プログラム２０が、ジョブボリューム管理テーブル２４の対応するエントリの障害フラグ欄２４Ｄに格納された障害フラグを「ＯＮ」に設定するようにしても良い。

さらにオペレーティングシステム２２（図１）が出力するストレージ障害メッセージをジョブ管理プログラム２０などが監視し、ジョブボリューム管理テーブル２４のエントリのうち、ストレージ障害メッセージに含まれるボリュームＩＤがボリュームＩＤ欄２４Ａに格納されたエントリの障害フラグ欄２４Ｄの障害フラグを「ＯＮ」に変更するようにしても良い。

さらにストレージ管理プログラム２１が、障害が発生したボリュームＶＯＬのボリュームＩＤをジョブ管理プログラム２０に通知し、この通知を受けたジョブ管理プログラム２０が、ジョブボリューム管理テーブル２４のエントリのうち、通知されたボリュームＩＤがボリュームＩＤ欄２４Ａに格納されたエントリの障害フラグ欄２４Ｄの障害フラグを「ＯＮ」に変更するようにしても良い。

図１１は、図９について上述したジョブ実行処理のステップＳＰ４においてジョブ管理プログラム２０が実行するボリューム障害チェック処理の具体的な処理内容を示している。

ジョブ管理プログラム２０は、ジョブ実行処理のステップＳＰ９に進むと、このボリューム障害チェック処理を開始し、まず、異常終了したジョブが利用したボリュームＶＯＬなど、障害の可能性があるボリュームＶＯＬについて障害の有無を検証する（ＳＰ２０〜ＳＰ２３）。

具体的にジョブ管理プログラム２０は、ジョブボリューム管理テーブル２４の各エントリをチェックして、チェック要因情報欄２４Ｃにチェック要因情報（対応するジョブのジョブＩＤ）が設定されているエントリがあるか否かを判断する（ＳＰ２０）。

そしてジョブ管理プログラム２０は、この判断において否定結果を得るとステップＳＰ２４に進み、これに対して肯定結果を得ると、チェック要因情報欄２４Ｃにチェック要因情報が格納された各エントリについて、そのボリュームＩＤ欄２４Ａに格納されたボリュームＩＤのボリュームＶＯＬに障害が発生したか否かの障害情報と、そのボリュームＶＯＬの副ボリュームＳＶＯＬが存在するか否かの複製情報との送信を、当該ボリュームＩＤを指定してストレージ管理プログラム２１（図１）に要求する（ＳＰ２１）。

なおステップＳＰ２１のかわりに、ジョブ管理プログラム２０が、ジョブボリューム管理テーブル２４の対応するエントリのマウントポイントパス欄２４Ｂに格納されたパス名が示すディレクトリや、その配下のファイル３３にアクセスして障害の有無を確かめるようにしても良い。またジョブ管理プログラム２０が、オペレーティングシステム２２に対してジョブボリューム管理テーブル２４の対応するエントリのボリュームＩＤ欄２４Ａに格納されたボリュームＩＤを送信することによって、対応するボリュームＶＯＬの障害情報を入手するようにしても良い。さらにジョブ管理プログラム２０が、ステップＳＰ２０を行わずに、そのとき実行しようとするジョブが利用するすべてのボリュームＶＯＬに対してステップＳＰ２１の処理を行うようにしても良い。

そしてジョブ管理プログラム２０は、ステップＳＰ２１の要求に応じてストレージ管理プログラム２１から送信されてきたかかるボリュームＶＯＬの障害情報に基づいて、当該ボリュームＶＯＬに障害が生じているか否かを判断する（ＳＰ２２）。そしてジョブ管理プログラム２０は、この判断において否定結果を得るとステップＳＰ２４に進み、これに対して肯定結果を得ると、ジョブボリューム管理テーブル２４の対応するエントリの障害フラグ欄２４Ｄに格納された障害フラグを「ＯＮ」に設定する（ＳＰ２３）。

なお、ジョブ管理プログラム２０が、ステップＳＰ２０〜ステップＳＰ２３の処理を行わずに、ステップＳＰ２４において、ジョブボリューム管理テーブル２４に、障害フラグ欄２４Ｄに格納された障害フラグが「ＯＮ」であるエントリも、またチェック要因情報欄２４Ｃにチェック要因情報が格納されたエントリも存在しないときに、このボリューム障害チェック処理を終了するようにしても良い。この場合、障害の可能性があるボリュームＶＯＬが含まれているときにはユーザに応答を求めるため、障害の有無の判断をストレージ管理プログラム２１の代わりにユーザが行うことになる。

続いてジョブ管理プログラム２０は、次に実行しようとしているジョブが利用するボリュームＶＯＬに障害が発生しているか否かを判断する（ＳＰ２４）。すなわち、ジョブ管理プログラム２０は、ジョブファイル管理テーブル２３のエントリのうち、ジョブＩＤ欄２３Ｃに格納されたジョブＩＤが、そのとき対象としているジョブ定義ファイル３２において定義されたジョブのジョブＩＤと一致するすべてのエントリを検出し、それらエントリのボリュームＩＤ欄２３Ｂにそれぞれ格納されているボリュームＩＤを検出する。そしてジョブ管理プログラム２０は、ジョブボリューム管理テーブル２４のエントリの中に、このようにして検出したボリュームＩＤがボリュームＩＤ欄２４Ａに格納され、かつ障害フラグ欄２４Ｄに格納された障害フラグが「ＯＮ」に設定されたエントリが存在するか否かを判断する。

この判断において否定結果を得ることは、そのとき対象としているジョブ定義ファイル３２において定義されたジョブが利用するボリュームＶＯＬに障害が発生していないことを意味する。かくして、このときジョブ管理プログラム２０は、このボリューム障害チェック処理を終了して図９について上述したジョブ実行処理に戻る。

これに対して、かかる判断において肯定結果を得ることは、そのとき対象としているジョブ定義ファイル３２において定義されたジョブが利用するボリュームＶＯＬに障害が発生していることを意味する。かくして、このときジョブ管理プログラム２０は、このボリュームＶＯＬに副ボリュームＳＶＯＬが存在するか否かを、ステップＳＰ２１の要求に応じてストレージ管理プログラム２１から送信されてきた複製情報に基づいて判断する（ＳＰ２５）。

そしてジョブ管理プログラム２０は、この判断において肯定結果を得ると、かかるジョブで使用するボリュームＶＯＬを、そのボリュームＶＯＬの副ボリュームＳＶＯＬに切り替える（ＳＰ２６〜ＳＰ２８）。

具体的にジョブ管理プログラム２０は、ステップＳＰ２５において検出した副ボリュームＳＶＯＬをマウントする（ＳＰ２６）。またジョブ管理プログラム２０は、その副ボリュームＳＶＯＬをジョブボリューム管理テーブル２４に登録する（ＳＰ２７）。より詳細には、ジョブ管理プログラム２０は、ジョブボリューム管理テーブル２４に新規エントリを割り当て、その新規エントリのボリュームＩＤ欄２４Ａに当該副ボリュームＳＶＯＬのボリュームＩＤを格納すると共に、その新規エントリのマウントポイントパス欄２４Ｂに当該副ボリュームＳＶＯＬのマウント先のディレクトリのパス名を格納する。

さらにジョブ管理プログラム２０は、ジョブファイル管理テーブル２３のエントリのうち、ステップＳＰ２６においてジョブボリューム管理テーブル２４に登録した副ボリュームＳＶＯＬの正ボリューム（つまり元々ジョブが使用する予定であったボリュームＶＯＬ）のボリュームＩＤがボリュームＩＤ欄２３Ｂに格納されたすべてのエントリについて、パス名欄２３Ａに格納されたパス名のうち、対応する副ボリュームＳＶＯＬのマウント先のパスと一致する先頭部分を、副ボリュームＳＶＯＬのマウントポイントパスに置換する（ＳＰ２８）。

続いてジョブ管理プログラム２０は、障害が発生したボリュームＶＯＬに残っている消去対象のファイル３３を消去すると共に、ジョブファイル管理テーブル２３（図３）の削除対象情報欄２３Ｅに「ＦＡＩＬＥＤ」という削除対象情報が格納されたエントリに対応するファイル３３を消去する（ＳＰ３１）。

具体的にジョブ管理プログラム２０は、ジョブボリューム管理テーブル２４のエントリのうち、ステップＳＰ２６〜ステップＳＰ２８において副ボリュームＳＶＯＬに切り替えられたボリュームＶＯＬに対応するエントリのチェック要因情報欄２４Ｃに格納されたチェック要因情報を消去すると共に、当該エントリの障害フラグ欄２４Ｄに格納された障害フラグを「ＯＦＦ」に変更する。またジョブ管理プログラム２０は、ジョブファイル管理テーブル２３のエントリのうち、かかる障害が発生したボリュームＶＯＬのボリュームＩＤがボリュームＩＤ欄２３Ｂに格納され、かつ削除対象情報欄２３Ｅに「ＹＥＳ」が格納されたエントリが存在するときには、そのエントリのパス名欄２３Ａに格納されたパス名が示すファイル３３を、かかる障害が発生したボリュームＶＯＬから削除する。次いでジョブ管理プログラム２０は、ジョブファイル管理テーブル２３からそのエントリを削除する。またジョブ管理プログラム２０は、上記処理と併せて、ジョブファイル管理テーブル２３上の削除対象情報欄２３Ｅに「ＦＡＩＬＥＤ」という削除対象情報が格納されたエントリを消去すると共に、当該エントリと対応するファイルを対応するボリュームＶＯＬから削除する。そしてジョブ管理プログラム２０は、この後、図９について上述したジョブ実行処理に戻る。

一方、ジョブ管理プログラム２０は、ステップＳＰ２５の判断において否定結果を得ると、そのとき対象としているジョブ定義ファイル３２において定義されたジョブのジョブＩＤと、そのジョブ定義ファイル３２において定義されている当該ジョブで利用するボリュームＶＯＬのボリュームＩＤと、ジョブボリューム管理テーブル２４の当該ボリュームＶＯＬと対応するエントリのチェック要因情報欄２４Ｃに格納された異常終了したジョブのジョブ名とを含む障害情報をコンソール５（図１）に通知する（ＳＰ２９）。

かくしてコンソール５は、この障害情報に基づいて、図１２に示すように、次に実行しようとするジョブが利用するボリュームＶＯＬに障害が発生しているおそれがあるため当該ジョブの実行を中断した旨のメッセージと、実行を中断したジョブのジョブＩＤと、そのジョブが利用するボリュームＶＯＬのボリュームＩＤと、そのボリュームＶＯＬを使用して異常終了したジョブのジョブＩＤとが表示された障害通知画面４１を表示する。かくしてユーザは、この障害通知画面４１内のＡＣＴＩＯＮ欄４１Ａにそのとき対象としているジョブを実行すべきことを意味する「Ｙ」又は当該ジョブの実行を中止すべきことを意味する「Ｎ」を入力することによって、かかるジョブを実行すべきか又は中止すべきかを選択することができる。

ただし、「ジョブを実行する」という選択肢を選択するに際しては、かかる障害が発生しているボリュームＶＯＬを障害から回復させるための回復作業（例えば対応するディスクドライブの交換作業等）を行なう必要がある。これは、かかる回復作業を行なわなければ、かかるジョブも異常終了することになるからである。

そしてコンソール５は、かかる障害情報画面４１のＡＣＴＩＯＮ欄４１Ａに「Ｙ」又は「Ｎ」が入力されると、「Ｙ」及び「Ｎ」のいずれが選択されたかをジョブ管理プログラム２０に通知する。

ジョブ管理プログラム２０は、かかる通知を受信すると、この通知に基づいて、そのとき対象としているジョブを中止すべきか否かを判断し（ＳＰ３０）、肯定結果を得ると、図９について上述したジョブ実行処理に戻って当該ジョブ実行処理のステップＳＰ１４に進む。

これに対してジョブ管理プログラム２０は、かかる判断において否定結果を得ると、上述と同様にしてステップＳＰ３１の処理を実行し、この後かかるジョブ実行処理に戻る。

なお上述のボリューム障害チェック処理において、ジョブ管理プログラム２０が、ステップＳＰ２１でストレージ管理プログラム２１から複製情報を取得し、ステップＳＰ２６で副ボリュームＳＶＯＬをマウントする代わりに、ユーザが副ボリュームＳＶＯＬをマウントして、正ボリュームＰＶＯＬ（つまりその副ボリュームＳＶＯＬに切り替えられる前の障害が発生したボリュームＶＯＬ）のマウントポイントパスのパス名と副ボリュームＳＶＯＬのマウントポイントパスのパス名とをコマンドによりジョブ管理プログラム２０に通知し、ステップＳＰ２７の処理を事前に行うようにしても良い。

次に、かかるボリューム障害チェック処理（図１１）のステップＳＰ２１において、ジョブ管理プログラム２０からボリュームＶＯＬの障害情報及び複製情報の送信要求を受けたストレージ管理プログラム２１が実行する障害複製情報送信処理の処理内容を図１３に示す。

ストレージ管理プログラム２１は、ジョブ管理プログラム２０からボリュームＶＯＬの障害情報及び複製情報を送信すべき旨の要求が与えられると、この障害複製情報送信処理を開始し、まず、そのとき対象とするボリュームＶＯＬのボリュームＩＤと、正ボリュームＩＤ欄２５Ａに格納されたボリュームＩＤとが一致するエントリをボリュームペア管理テーブル２５上で検索する。そしてストレージ管理プログラム２１は、この検索によりボリュームＩＤが一致するエントリを検出すると、そのエントリの副ボリュームＳＶＯＬのボリュームＩＤをジョブ管理プログラム２０に送信する。（ＳＰ４０）。なおストレージ管理プログラム２１は、予めストレージ装置４内に設定された各ボリュームペアの正ボリュームＰＶＯＬのボリュームＩＤ及び副ボリュームＳＶＯＬのボリュームＩＤをストレージ装置４から取得し、取得した情報に基づいてこのボリュームペア管理テーブル２５を作成する。

次いでストレージ管理プログラム２１は、かかる問合せ対象のボリュームＶＯＬのボリュームＩＤと、ボリュームＩＤ欄２６Ａに格納されたボリュームＩＤとが一致するエントリをボリューム管理テーブル２６上で検索する。そしてストレージ管理プログラム２１は、この検索によりボリュームＩＤが一致するエントリを検出すると、そのエントリの障害フラグ欄２６Ｂに格納されたボリューム障害フラグの内容（「ＯＮ」又は「ＯＦＦ」）をジョブ管理プログラム２０に送信する（ＳＰ４１）。なおストレージ管理プログラム２１は、ステップＳＰ４１の前又は一定時間ごとにストレージ装置４又は計算機２のオペレーティングシステム２２（図１）に対してボリューム障害の有無を問い合わせ、得られたボリューム障害情報に基づいてボリューム管理テーブル２６の対応するボリューム障害フラグを必要に応じて更新する。

続いてストレージ管理プログラム２１は、かかる問合せ対象のボリュームＶＯＬのボリュームＩＤと、ボリュームＩＤ欄２７Ａに格納されたボリュームＩＤとが一致するエントリをボリュームパス管理テーブル２７上で検索する。そしてストレージ管理プログラム２１は、この検索によりボリュームＩＤが一致するエントリを検出すると、そのエントリのパスＩＤ欄２７Ｂに格納された対応するパスのパスＩＤを取得する（ＳＰ４２）。

またストレージ管理プログラム２１は、上述のようにして得られたパスＩＤと、パスＩＤ欄２８Ａに格納されたパスＩＤが一致するエントリをパス管理テーブル２８上で検索し、当該検索により検出したエントリのパス障害フラグ欄２８Ｂに格納されたパス障害フラグの内容（「ＯＮ」又は「ＯＦＦ」）をジョブ管理プログラム２０に送信する（ＳＰ４３）。そしてストレージ管理プログラム２１は、この後、この障害複製情報送信処理を終了する。なおストレージ管理プログラム２１は、ステップＳＰ４１の前又は一定時間ごとにストレージ装置３又は計算機２のオペレーティングシステム２２に各パスＩＤが示すパス（通信経路）についての障害の有無を問い合わせ、得られたパス障害情報に基づいてパス管理テーブル２８のパス障害フラグ欄２８Ｂを必要に応じて更新する。

（３）本実施の形態の効果
以上のように本計算機システム１では、バッチ処理において、ジョブを実行する前に、当該ジョブが利用するボリュームＶＯＬや当該ボリュームＶＯＬ及び計算機２間のパスに障害又は障害発生のおそれがあるか否かをチェックし、障害又は障害発生のおそれがあるときには、ユーザにその旨を通知してユーザからの許可があるまで後続するジョブの実行を延期するため、異常終了したジョブの異常終了要因をユーザが容易に特定することができる。かくするにつきジョブが異常終了した場合においても、ユーザが異常終了要因を特定し、再スケジュールするという作業を省くことができ、かくしてバッチジョブ運用を省力化し得る計算機システムを実現することができる。

（４）他の実施の形態
なお上述の実施の形態においては、本発明を図１のように構成された計算機システム１の計算機１に適用するようにした場合について述べたが、本発明はこれに限らず、要は、バッチ処理を行ない得るようになされたこの他種々の情報処理装置に広く適用することができる。

また上述の実施の形態においては、バッチ処理の次のジョブを実行する前にそのジョブが利用するボリュームＶＯＬや、計算機２及び当該ボリュームＶＯＬ間のパスについての障害の有無をチェックするようにした場合について述べたが、本発明はこれに限らず、ボリュームＶＯＬ及びパス以外の次のジョブが利用する他の資源についても障害の有無をチェックするようにしても良い。

さらに上述の実施の形態においては、障害通知画面４０，４１を図１０や図１２のように構成するようにした場合について述べたが、本発明はこれに限らず、この他種々の構成を広く適用することができる。

本発明は、バッチ処理機能が搭載された種々の情報処理装置に広く適用することができる。

本実施の形態による計算機システムの全体構成を示すブロック図である。 ジョブ定義ファイルの記述例を示す概念図である。 ジョブファイル管理テーブルの構成例を示す概念図である。 ジョブボリューム管理テーブルの構成例を示す概念図である。 ボリュームペア管理テーブルの構成例を示す概念図である。 ボリューム管理テーブルの構成例を示す概念図である。 ボリュームパス管理テーブルの構成例を示す概念図である。 パス管理テーブルの構成例を示す概念図である。 ジョブ実行処理の処理手順を示すフローチャートである。 障害通知画面の表示例を示す略線図である。 ボリューム障害チェック処理の処理手順を示すフローチャートである。 障害通知画面の表示例を示す略線図である。 障害複製情報送信処理の処理手順を示すフローチャートである。

符号の説明

１……計算機システム、２……計算機、３……ストレージ装置、５……コンソール、１０……主記憶装置、１１……ＣＰＵ、２０……ジョブ管理プログラム、２１……ストレージ管理プログラム、２３……ジョブファイル管理テーブル、２４……ジョブボリューム管理テーブル、２５……ボリュームペア管理テーブル、２６……ボリューム管理テーブル、２７……ボリュームパス管理テーブル、２８……パス管理テーブル、３０……ストレージ部、３１……コントローラ部、３２……ジョブ定義ファイル、３３……ファイル、ＶＯＬ……ボリューム、ＰＶＯＬ……正ボリューム、ＳＶＯＬ……副ボリューム、４０，４１……障害通知画面。

Claims (11)

1. プログラムが格納された主記憶装置と、
   前記主記憶装置に格納された前記プログラムに従って所定の資源を利用するバッチ処理を実行するプロセッサと
   を備え、
   前記プロセッサは、
   前記バッチ処理のうちの次に実行するジョブが利用する前記資源を特定すると共に、当該資源に障害が発生しているか否かを判定し、
   当該資源に障害が発生していると判定したときには、当該障害に関する障害情報をユーザに提示し、ユーザからの応答を得るまで当該ジョブの実行を延期する
   ことを特徴とするバッチ処理装置。
2. 前記資源は、ストレージ装置内に設けられた論理ボリュームである
   ことを特徴とする請求項１に記載のバッチ処理装置。
3. 前記資源は、さらに前記ボリュームまでのパスを含む
   ことを特徴とする請求項２に記載のバッチ処理装置。
4. 前記プロセッサは、
   次に実行する前記ジョブが使用する前記資源が、前記バッチ処理のうちの既に実行済みのジョブのうち、異常終了したジョブが使用した資源であるか否かに基づいて、次に実行する前記ジョブが使用する前記資源に障害が発生しているか否かを判定する
   ことを特徴とする請求項１に記載のバッチ処理装置。
5. 障害が発生した前記論理ボリュームの複製が存在するときには、前記ジョブの実行を延期することなく、当該ジョブが利用する前記論理ボリュームを当該複製に切り替えて当該ジョブを実行する
   ことを特徴とする請求項２に記載のバッチ処理装置。
6. 所定の資源を利用するバッチ処理を実行するバッチ処理方法において、
   前記バッチ処理のうちの次に実行するジョブが利用する前記資源を特定すると共に、当該資源に障害が発生しているか否かを判定する第１のステップと、
   当該資源に障害が発生していると判定したときには、当該障害に関する障害情報をユーザに提示し、ユーザからの応答を得るまで当該ジョブの実行を延期する第２のステップと
   を備えることを特徴とするバッチ処理方法。
7. 前記資源は、ストレージ装置内に設けられた論理ボリュームである
   ことを特徴とする請求項６に記載のバッチ処理方法。
8. 前記資源は、さらに前記ボリュームまでのパスを含む
   ことを特徴とする請求項７に記載のバッチ処理方法。
9. 前記第１のステップでは、
   次に実行する前記ジョブが使用する前記資源が、前記バッチ処理のうちの既に実行済みのジョブのうち、異常終了したジョブが使用した資源であるか否かに基づいて、次に実行する前記ジョブが使用する前記資源に障害が発生しているか否かを判定する
   ことを特徴とする請求項６に記載のバッチ処理方法。
10. 前記第２のステップでは、
    障害が発生した前記論理ボリュームの複製が存在するときには、前記ジョブの実行を延期することなく、当該ジョブが利用する前記論理ボリュームを当該複製に切り替えて当該ジョブを実行する
    ことを特徴とする請求項７に記載のバッチ処理方法。
11. 所定の資源を利用するバッチ処理を実行するバッチ処理のうちの次に実行するジョブが利用する前記資源を特定すると共に、当該資源に障害が発生しているか否かを判定する第１のステップと、
    当該資源に障害が発生していると判定したときには、当該障害に関する障害情報をユーザに提示し、ユーザからの応答を得るまで当該ジョブの実行を延期する第２のステップと
    を備えることを特徴とする処理をコンピュータに実行させるプログラム。

Images