コンピュータシステム及びリカバリ方法
【課題】コンピュータ上で動作しているアプリケーションに障害が発生した場合、障害の原因を判断し、予め登録したリカバリ情報を取得して、障害を回復させること。
【解決手段】リカバリシステム108は、障害が発生したユーザシステム102から起動され、ユーザシステム102から送られてきた障害発生時の入力データ及びエラーコードを受取り、リカバリ対応ＤＢ検索手段111が、リカバリ対応ＤＢ114を検索し、対応要否が対応要を示していた場合、障害発生時の障害内容に対応する補完データを取得し、リカバリ手段112が、ユーザシステムから送られてきた障害発生時の入力データの修復を行い、ユーザシステム112に、修復したデータを送信し、障害発生の以後の後続処理を続けさせる。
【解決手段】リカバリシステム108は、障害が発生したユーザシステム102から起動され、ユーザシステム102から送られてきた障害発生時の入力データ及びエラーコードを受取り、リカバリ対応ＤＢ検索手段111が、リカバリ対応ＤＢ114を検索し、対応要否が対応要を示していた場合、障害発生時の障害内容に対応する補完データを取得し、リカバリ手段112が、ユーザシステムから送られてきた障害発生時の入力データの修復を行い、ユーザシステム112に、修復したデータを送信し、障害発生の以後の後続処理を続けさせる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステム及びリカバリ方法に係り、特に、オープン系コンピュータシステムで障害が発生した場合に、その原因を特定して障害部位を自動的に回復させることを可能にしたコンピュータシステム及びリカバリ方法に関する。
【背景技術】
【０００２】
コンピュータ装置に障害が発生した場合に、その原因を特定して障害部位を回復させるための従来技術として、例えば、特許文献１等に記載された技術が知られている。この従来技術は、コンピュータ装置に障害が発生した場合、赤外線通信が可能な保守者が持つ携帯情報端末が、保守対象である障害が発生したコンピュータ装置に動作履歴を示すログ情報を含む装置情報を送信するように要求し、要求を受けたコンピュータ装置が、要求された装置情報を携帯情報端末に送信し、これを受信した携帯情報端末が、通信可能なサーバ装置に対し、コンピュータ装置から供給された装置情報を通知し、供給されたログ情報に関連付けられた障害内容を示す保守情報を予め保持しているサーバ装置が、携帯情報端末から装置情報を含むログ情報を通知された際に、通知された装置情報に対応する保守情報の選定を行い、この保守情報を携帯情報端末へ送信するというものである。これにより、保守者は、コンピュータ装置の障害原因の究明と復旧とを速やかに行うことが可能となる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−１３９５７２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
一般に、コンピュータ装置上で動作しているアプリケーションに障害が発生した場合、プログラムの実行を中断し、第１ステップとして障害原因の特定を行う。そして、障害原因の特定ができた場合、第２ステップとして入力データの修復を行いプログラムの再実行を行う。原因の特定は、障害検知箇所、入力データを調査するため、多くの人手と時間を必要とし、障害回復の遅延が発生する。また、入力データの修復を行いプログラムの再実行を行うには、人為的判断を要するため、回復処理に誤りが生じ、二次災害に繋がるリスクがある。
【０００５】
前述した従来技術は、原因の特定、入力データの修復、プログラムの再実行を人手により行わなければならず、多くの人手と時間を必要とし、回復処理に誤りが生じ、二次災害に繋がるリスクがあるという問題を解決することができないものである。
【０００６】
本発明の目的は、前述した従来技術が有する問題を解決するため、コンピュータ上で動作しているアプリケーションに障害が発生した場合、障害の原因を機械的に判断し、予め登録したリカバリ情報を取得して、入力データを修復しプログラムの再実行を行うまでの一連の処理を自動的に行うことを可能にしたコンピュータシステム及びリカバリ方法を提供することにある。
【課題を解決するための手段】
【０００７】
本発明によれば前記目的は、ユーザシステムと、該ユーザシステムに障害が発生した場合に、障害の原因を特定して障害を回復させるリカバリシステムとにより構成されるコンピュータシステムにおいて、前記リカバリシステムは、前記ユーザシステムから受け取ったエラーコード、リカバリシステムでの対応の要否を示す対応要否、補完するデータを示す補完データを格納しているリカバリ対応ＤＢと、該リカバリ対応ＤＢを検索するリカバリ対応ＤＢ検索手段と、リカバリ手段とを備え、前記ユーザシステムに障害が発生したとき、前記ユーザシステムから起動され、前記ユーザシステムから送られてきた障害発生時の入力データ及びエラーコードを受取り、前記リカバリ対応ＤＢ検索手段が、前記リカバリ対応ＤＢを検索し、対応要否が対応要を示していた場合、障害発生時の障害内容に対応する補完データを取得し、前記リカバリ手段が、前記ユーザシステムから送られてきた障害発生時の入力データの修復を行い、前記ユーザシステムに、修復したデータを送信し、障害発生の以後の後続処理を続けさせることにより達成される。
【発明の効果】
【０００８】
本発明によれば、人手と時間を必要とすることなく、障害を発生させたプログラムのリカバリ対応が可能となり、また、人為的判断ミスが無くなるため、回復作業誤りによる二次災害のリスクを抑止することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の一実施形態によるコンピュータシステムの構成例を示すブロック図である。
【図２】コード変換機能の処理動作を説明するフローチャートである。
【図３】ジャーナル変換機能の処理動作を説明するフローチャートである。
【図４】リカバリ対応ＤＢ検索機能の処理動作を説明するフローチャートである。
【図５】リカバリ機能の処理動作を説明するフローチャートである。
【図６】レイアウト定義ＤＢの構成を説明する図である。
【図７】リカバリ対応ＤＢの構成を説明する図である。
【図８】ＳＡＭファイル内に保持されているユーザジャーナル（変換前）の構成を説明する図である。
【図９】ＳＡＭファイル内に保持されているユーザジャーナル（変換後）の構成を説明する図である。
【図１０】エラーコード、文字コードのパラメータの構成を説明する図である。
【発明を実施するための形態】
【００１０】
以下、本発明によるコンピュータシステムの実施形態を図面により詳細に説明する。
【００１１】
図１は本発明の一実施形態によるコンピュータシステムの構成例を示すブロック図である。なお、以下の説明において、同一名を持つ構成要素であっても、図毎にそれらの要素に付与した符号が異なっているが、同一名であれば同一の構成要素である。
【００１２】
本発明の一実施形態によるコンピュータシステムは、サーバマシン１０１上で稼動するように、サーバマシン１０１内にユーザシステム１０２及び自動リカバリシステム１０８が構築されて構成されている。サーバマシン１０１は、図示していないが、主メモリ、ＨＤＤ等による記憶装置、マシン全体の制御を行うＣＰＵ、ユーザシステム１０２を使用するユーザが利用するためにユーザシステム１０２に接続されるキーボード、マウス、表示装置等の入出力装置に対するインターフェース等を備えて構成されている。
【００１３】
そして、ユーザシステム１０２及び自動リカバリシステム１０８は、サーバマシン１０１の記憶装置内に格納されたプログラムを主メモリにロードしてＣＰＵが実行することにより構築される。また、以下に説明する本発明の実施形態での処理も、前述と同様に、サーバマシン１０１の記憶装置内に格納されたプログラムが主メモリにロードされてＣＰＵにより実行される。
【００１４】
前述において、ユーザシステム１０２は、バッチ、または、オンラインプログラム等の実行中に発生した障害を障害検知手段１０３が検知すると、自動リカバリシステム呼出し手段１０４が、自動リカバリシステム１０８の呼出しを行う。
【００１５】
自動リカバリシステム呼出し手段１０４は、自動リカバリシステム１０８の呼出しを行う際に、障害発生の起因となった入力データをユーザジャーナルとして取得し、ＳＡＭファイル１０５（その構成については図８を参照して後述する）へ出力する。ユーザジャーナルは、ミドルウェアが提供するコマンドを発行することことにより取得することが可能である。例えば、日立オープンミドルウェアの１つであるＯｐｅｎＴＰ１の場合、ジャーナルスワップ、ジャーナルエディット等のコマンドを発行することによりユーザジャーナルを取得することができる。
【００１６】
ユーザシステム１０２は、ＳＡＭファイル１０５内のユーザジャーナル、発生した障害の内容に対応したエラーコード１０６、及び、ユーザシステムで取り扱う文字コード１０７をパラメータとして設定した呼出し要求を行って自動リカバリシステム１０８の呼出しを行う。
【００１７】
自動リカバリシステム１０８は、コード変換機能１０９、ジャーナル変換機能１１０、リカバリ対応ＤＢ検索機能１１１、リカバリ機能１１２の４つの処理部により構成され、また、レイアウト定義ＤＢ１１３、リカバリ対応ＤＢ１１４を備えている。レイアウト定義ＤＢ１１３、リカバリ対応ＤＢ１１４は、予め必要なデータが登録されており、ジャーナル変換機能１１０、リカバリ対応ＤＢ検索機能１１１により参照される。
【００１８】
自動リカバリシステム１０８は、コード変換機能１０９、ジャーナル変換機能１１０、リカバリ対応ＤＢ検索機能１１１、リカバリ機能１１２の４つの処理部が順に処理を実行して、障害の起因となった情報を修復する。リカバリされた情報は、ユーザシステム１０２に戻され、これにより、ユーザシステム１０２は、人手を介することなく自動的に障害の発生後の後続処理１１５を継続して実行することが可能となる。
【００１９】
図２はコード変換機能１０９の処理動作を説明するフローチャートであり、次に、これについて説明する。コード変換機能１０９は、ユーザジャーナル入力処理２０１、文字コード変換処理２０２、変換後データ出力処理２０３の３つの処理部から構成される。以下では、これらの３つの処理部での処理動作としてコード変換機能１０９の処理動作を説明する。
【００２０】
（１）ユーザジャーナル入力処理２０１は、ＳＡＭファイル２０４内のユーザジャーナル読込みを行い、変換前のユーザジャーナルのデータをプログラム内部のバッファメモリ上に展開する。
【００２１】
（２）次に、文字コード変換処理２０２は、入力ファイルの様々な種類の文字コードに対して、一律にＳＪＩＳコードへ変換処理を行う。変換前の文字コードについては、文字コード２０５のパラメータ（その構成については図１０を参照して後述する）に登録されているためそれに従う。
【００２２】
（３）次に、変換後データ出力処理２０３は、文字コード変換処理２０２がＳＪＩＳコードへ変換したユーザジャーナルデータをＳＡＭファイル２０６出力する。
【００２３】
図３はジャーナル変換機能１１０の処理動作を説明するフローチャートであり、次に、これについて説明する。ジャーナル変換機能１１０は、レイアウト定義の取得処理３０１、テキスト形式への変換処理３０２、変換後データ取得処理３０３の３つの処理部から構成される。以下では、これらの３つの処理部での処理動作としてジャーナル変換機能１１０の処理動作を説明する。
【００２４】
（１）レイアウト定義の取得処理３０１は、レイアウト定義ＤＢ（その構成については図６を参照して後述する）３０４からユーザジャーナルのレイアウト定義の情報を取得する。レイアウト定義ＤＢ３０４は、ユーザプログラムの実行環境毎に登録することが可能とされており、例えば、実行環境Ａで取得するユーザジャーナルのレイアウト定義を登録し、または、実行環境Ｂにて取得するユーザジャーナルのレイアウト定義を登録することが可能である。
【００２５】
（２）次に、テキスト形式への変換処理３０２は、ＳＡＭファイル３０５内の変換前のユーザジャーナルデータを入力として、レイアウト定義ＤＢ３０４内に登録されているレイアウト定義の情報の内、有効フラグがオンになっている方のレイアウト定義を参照し、それに従いテキスト形式への変換処理を実行する。ＳＡＭファイル３０５内のデータレコードは、図３（ａ）にユーザジャーナル３０７として示しているように、左側部が１６進数の形式、右側部が楕円で囲んで示しているようにテキスト形式で表示されており、４バイト区切りで空白部が存在していたり、１６バイトで改行が行われていたりするなど特異な形式で表示されている。そして、テキスト形式への変換処理３０２は、図３（ｂ）に前述の右側部のテキスト形式の変換前のデータを３０８として示すように取出し、定型の区切り空白部分と改行を除外して、入力情報をテキスト文字列形式へのと変換処理を行い、図３（ｃ）に３０９として示しているように、入力されたままの元データの復元を行う。
【００２６】
（３）次に、変換後データ出力処理３０３は、テキスト形式への変換処理３０２により変換された変換後のユーザジャーナルデータ３０９をＳＡＭファイル（その構成については図９を参照して後述する）３０６へ出力する。
【００２７】
図４はリカバリ対応ＤＢ検索機能１１１の処理動作を説明するフローチャートであり、次に、これについて説明する。リカバリ対応ＤＢ検索機能１１１は、リカバリ対応ＤＢ検索処理４０１、対応内容と対応要否の取得処理４０２の２つの処理部から構成される。以下では、これらの２つの処理部での処理動作としてリカバリ対応ＤＢ検索機能１１１の処理動作を説明する。
【００２８】
（１）リカバリ対応ＤＢ検索処理４０１は、エラーコード４０３のパラメータとして受け取ったエラーコード（その構成については図１０を参照して後述する）を使用し、リカバリ対応ＤＢ（その構成については図７を参照して後述する）４０４を検索する。リカバリ対応ＤＢ４０４には、予めエラーコードに対応したリカバリ方法が登録されている。
【００２９】
（２）対応内容と対応要否の取得処理４０２の処理は、リカバリ対応ＤＢ検索処理４０１が検索処理で取得したリカバリ処理の対応要否と対応内容の情報とをプログラム内部のバッファメモリ上に展開する。
【００３０】
図５はリカバリ機能１１２の処理動作を説明するフローチャートであり、次に、これについて説明する。リカバリ機能１１２は、対応要否の判断処理５０１、エラーのリカバリ処理５０２の２つの処理部から構成される。以下では、これらの２つの処理部での処理動作としてリカバリ機能１１２の処理動作を説明する。
【００３１】
（１）対応要否の判断処理５０１は、リカバリ対応ＤＢ検索処理４０１が検索処理で取得したリカバリ処理の対応要否と対応内容の情報とからリカバリ処理の対応の要否を判定し、リカバリ不要の場合、何の処理を行わずにここでの処理を終了する。
【００３２】
（２）リカバリ処理の対応の要否判断処理５０１の判定で、リカバリ要と判定した場合、リカバリ処理５０２は、元のデータへ変換された後のユーザジャーナルをＳＡＭファイル５０３から入力して、リカバリ対応ＤＢ４０４から取得した対応内容に従ってデータの補正を行う。リカバリ対応ＤＢ４０４には、補完データと補完ポイントとのバイト位置情報が予め登録されており、補完ポイントは、ユーザジャーナルデータの何バイト目から何バイト分のデータを補正するかを決定するために利用され、補完データは、そのポイントに対してデータの修復のためのデータである。
【００３３】
次に、対応内容の例について説明する。ＳＡＭファイル５０３のデータには、図５（ａ）に修正前のデータ５０５として示すように、５バイト目から４バイト（各バイトを△で示す）分が空白となっており、ユーザプログラムは、この空白となっている部分の必須項目が未入力と判断してエラーを検知した。
【００３４】
リカバリ対応ＤＢ４０４には、予め必須項目が未入力の場合を想定し、図５（ｂ）にリカバリ対応ＤＢの対応内容５０６として示すように、障害修復の対応内容として、未入力の場合、９９９９というデータで補完するように登録済である。前述した図５に示すフローでの処理の場合、修正前データ５０５の５バイト目から４バイトに９９９９が補完され、修正後のユーザジャーナルのデータは、図５（ｃ）に５０７として示すようなものに修正されることになる。
【００３５】
前述で説明したように、リカバリ処理５０２で修正されたユーザジャーナルデータは、ＳＡＭファイル５０４へ出力され、この修正後データは、引き続きユーザシステム１０２側で入力情報として取り込まれて後続処理を実行することができる。これにより、ユーザシステム１０２は、障害発生時に処理を中断することなく自動的に処理を継続することが可能となる。
【００３６】
図６はレイアウト定義ＤＢの構成を説明する図である。レイアウト定義ＤＢには、図６（ａ）に示すように、ユーザプログラムの実行環境毎に付与されるパターンＩＤと、テキスト形式の取得開始位置を示すテキスト開始位置と、連続で記載されている文字数を示す連続文字数と、テキスト形式の改行までの文字数を示す１行当りの文字数と、現在の実行環境に対してフラグがオンとされる有効フラグとが１組のデータとして、ユーザプログラムの実行環境毎に複数のデータの組がそれぞれ１つのレコードとして格納される。レイアウト定義ＤＢは、図６（ｂ）、図６（ｃ）に実行環境Ａ、Ｂの場合のデータ例として示しているようなデータを含むレコードがレイアウト定義として格納される場合、図６（ｄ）に示しているようなレコードとして保持することになる。
【００３７】
図７はリカバリ対応ＤＢの構成を説明する図である。リカバリ対応ＤＢには、図７（ａ）に示すように、ユーザプログラムから受け取ったエラーコードを示すエラーコードと、自動リカバリシステムでの対応の要否を示す対応要否と、補完するデータを示す補完データと、補完を行う開始位置を示す補完ポイントとが１組データとして、エラーコード毎に複数の組のそれぞれが１つのレコードとして格納される。そして、リカバリ対応ＤＢには、図７（ｂ）にデータ例として、エラーコードＸＸＸの必須項目が未入力、エラーコードＹＹＹの数字項目不正、エラーコードＺＺＺの区分値不正の場合のレコードの例として示しているようなレコードが格納されており、これらのレコードの場合、図７（ｃ）に示す修正前のデータが、図７（ｄ）に修正後のデータとして示すように修正されることになる。
【００３８】
図８はＳＡＭファイル内に保持されているユーザジャーナル（変換前）の構成を説明する図である。ＳＡＭファイルには、図８（ａ）に示すように、障害発生の起因となった入力データであるジャーナルファイルのデータのレコードであるジャーナルデータが１つのレコードとして、複数のレコードが格納されている。入力データが、図８（ｂ）にメインフレームからのユーザジャーナルの情報として示しているようなデータの場合、ＳＡＭファイル内には、図８（ｃ）に変換前のジャーナルデータとして示すようなデータとして格納される。
【００３９】
図９はＳＡＭファイル内に保持されているユーザジャーナル（変換後）の構成を説明する図である。ＳＡＭファイルには、図９（ａ）に示すように、障害発生の起因となった入力データであるジャーナルファイルのデータのレコードであるジャーナルデータが１つのレコードとして、複数のレコードが格納されている。入力データが、図８に示した変換前の場合と同様に、図９（ｂ）にメインフレームからのユーザジャーナルの情報として示しているようなデータの場合、ＳＡＭファイル内には、図９（ｃ）に変換後のジャーナルデータとして示すようなデータが格納される。
【００４０】
図１０はエラーコード、文字コードのパラメータの構成を説明する図である。エラーコードは、図１０（ａ）に示しているようなエラー内容を特定することができるコードであり、エラーコードのデータ例としては、必須項目が未入力の場合のエラーコードＸＸＸ、数字項目不正である場合のエラーコードＹＹＹ、区分値不正である場合のエラーコードＺＺＺ等のエラーコードがある。また、文字コードは、図１０（ｂ）に示しているような自動リカバリーシステム１０８で取り扱う文字コードであり、文字コードの例としては、データ例に０として示すＳＪＩＳ、データ例に１として示すＥＢＣＤＩＣ、データ例に２として示すＵＮＩＣＯＤＥ、データ例に３として示すＥＩＧ等がある。
【００４１】
前述した本発明の実施形態によれば、オープン系のコンピュータシステムにおいて、プログラム処理中に発生した障害に対する修復データを予め登録しておくこととし、プログラム処理中に障害が発生した場合、リカバリシステムが登録されている修復データを利用して機械的にデータ修復まで行うことができるため、人手と時間を必要とすることなく、障害を発生させたプログラムのリカバリ対応が可能となり、また、人為的判断ミスが無くなるため、回復作業誤りによる二次災害のリスクを抑止することができる。
【符号の説明】
【００４２】
１０１ サーバマシン
１０２ ユーザシステム
１０３ 障害検知手段
１０４ 自動リカバリシステム呼出し手段１０４
１０５ ＳＡＭファイル
１０８ 自動リカバリシステム
１０９ コード変換機能
１１０ ジャーナル変換機能
１１１ リカバリ対応ＤＢ検索機能
１１２ リカバリ機能
１１３ レイアウト定義ＤＢ
１１４ リカバリ対応ＤＢ
【技術分野】
【０００１】
本発明は、コンピュータシステム及びリカバリ方法に係り、特に、オープン系コンピュータシステムで障害が発生した場合に、その原因を特定して障害部位を自動的に回復させることを可能にしたコンピュータシステム及びリカバリ方法に関する。
【背景技術】
【０００２】
コンピュータ装置に障害が発生した場合に、その原因を特定して障害部位を回復させるための従来技術として、例えば、特許文献１等に記載された技術が知られている。この従来技術は、コンピュータ装置に障害が発生した場合、赤外線通信が可能な保守者が持つ携帯情報端末が、保守対象である障害が発生したコンピュータ装置に動作履歴を示すログ情報を含む装置情報を送信するように要求し、要求を受けたコンピュータ装置が、要求された装置情報を携帯情報端末に送信し、これを受信した携帯情報端末が、通信可能なサーバ装置に対し、コンピュータ装置から供給された装置情報を通知し、供給されたログ情報に関連付けられた障害内容を示す保守情報を予め保持しているサーバ装置が、携帯情報端末から装置情報を含むログ情報を通知された際に、通知された装置情報に対応する保守情報の選定を行い、この保守情報を携帯情報端末へ送信するというものである。これにより、保守者は、コンピュータ装置の障害原因の究明と復旧とを速やかに行うことが可能となる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−１３９５７２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
一般に、コンピュータ装置上で動作しているアプリケーションに障害が発生した場合、プログラムの実行を中断し、第１ステップとして障害原因の特定を行う。そして、障害原因の特定ができた場合、第２ステップとして入力データの修復を行いプログラムの再実行を行う。原因の特定は、障害検知箇所、入力データを調査するため、多くの人手と時間を必要とし、障害回復の遅延が発生する。また、入力データの修復を行いプログラムの再実行を行うには、人為的判断を要するため、回復処理に誤りが生じ、二次災害に繋がるリスクがある。
【０００５】
前述した従来技術は、原因の特定、入力データの修復、プログラムの再実行を人手により行わなければならず、多くの人手と時間を必要とし、回復処理に誤りが生じ、二次災害に繋がるリスクがあるという問題を解決することができないものである。
【０００６】
本発明の目的は、前述した従来技術が有する問題を解決するため、コンピュータ上で動作しているアプリケーションに障害が発生した場合、障害の原因を機械的に判断し、予め登録したリカバリ情報を取得して、入力データを修復しプログラムの再実行を行うまでの一連の処理を自動的に行うことを可能にしたコンピュータシステム及びリカバリ方法を提供することにある。
【課題を解決するための手段】
【０００７】
本発明によれば前記目的は、ユーザシステムと、該ユーザシステムに障害が発生した場合に、障害の原因を特定して障害を回復させるリカバリシステムとにより構成されるコンピュータシステムにおいて、前記リカバリシステムは、前記ユーザシステムから受け取ったエラーコード、リカバリシステムでの対応の要否を示す対応要否、補完するデータを示す補完データを格納しているリカバリ対応ＤＢと、該リカバリ対応ＤＢを検索するリカバリ対応ＤＢ検索手段と、リカバリ手段とを備え、前記ユーザシステムに障害が発生したとき、前記ユーザシステムから起動され、前記ユーザシステムから送られてきた障害発生時の入力データ及びエラーコードを受取り、前記リカバリ対応ＤＢ検索手段が、前記リカバリ対応ＤＢを検索し、対応要否が対応要を示していた場合、障害発生時の障害内容に対応する補完データを取得し、前記リカバリ手段が、前記ユーザシステムから送られてきた障害発生時の入力データの修復を行い、前記ユーザシステムに、修復したデータを送信し、障害発生の以後の後続処理を続けさせることにより達成される。
【発明の効果】
【０００８】
本発明によれば、人手と時間を必要とすることなく、障害を発生させたプログラムのリカバリ対応が可能となり、また、人為的判断ミスが無くなるため、回復作業誤りによる二次災害のリスクを抑止することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の一実施形態によるコンピュータシステムの構成例を示すブロック図である。
【図２】コード変換機能の処理動作を説明するフローチャートである。
【図３】ジャーナル変換機能の処理動作を説明するフローチャートである。
【図４】リカバリ対応ＤＢ検索機能の処理動作を説明するフローチャートである。
【図５】リカバリ機能の処理動作を説明するフローチャートである。
【図６】レイアウト定義ＤＢの構成を説明する図である。
【図７】リカバリ対応ＤＢの構成を説明する図である。
【図８】ＳＡＭファイル内に保持されているユーザジャーナル（変換前）の構成を説明する図である。
【図９】ＳＡＭファイル内に保持されているユーザジャーナル（変換後）の構成を説明する図である。
【図１０】エラーコード、文字コードのパラメータの構成を説明する図である。
【発明を実施するための形態】
【００１０】
以下、本発明によるコンピュータシステムの実施形態を図面により詳細に説明する。
【００１１】
図１は本発明の一実施形態によるコンピュータシステムの構成例を示すブロック図である。なお、以下の説明において、同一名を持つ構成要素であっても、図毎にそれらの要素に付与した符号が異なっているが、同一名であれば同一の構成要素である。
【００１２】
本発明の一実施形態によるコンピュータシステムは、サーバマシン１０１上で稼動するように、サーバマシン１０１内にユーザシステム１０２及び自動リカバリシステム１０８が構築されて構成されている。サーバマシン１０１は、図示していないが、主メモリ、ＨＤＤ等による記憶装置、マシン全体の制御を行うＣＰＵ、ユーザシステム１０２を使用するユーザが利用するためにユーザシステム１０２に接続されるキーボード、マウス、表示装置等の入出力装置に対するインターフェース等を備えて構成されている。
【００１３】
そして、ユーザシステム１０２及び自動リカバリシステム１０８は、サーバマシン１０１の記憶装置内に格納されたプログラムを主メモリにロードしてＣＰＵが実行することにより構築される。また、以下に説明する本発明の実施形態での処理も、前述と同様に、サーバマシン１０１の記憶装置内に格納されたプログラムが主メモリにロードされてＣＰＵにより実行される。
【００１４】
前述において、ユーザシステム１０２は、バッチ、または、オンラインプログラム等の実行中に発生した障害を障害検知手段１０３が検知すると、自動リカバリシステム呼出し手段１０４が、自動リカバリシステム１０８の呼出しを行う。
【００１５】
自動リカバリシステム呼出し手段１０４は、自動リカバリシステム１０８の呼出しを行う際に、障害発生の起因となった入力データをユーザジャーナルとして取得し、ＳＡＭファイル１０５（その構成については図８を参照して後述する）へ出力する。ユーザジャーナルは、ミドルウェアが提供するコマンドを発行することことにより取得することが可能である。例えば、日立オープンミドルウェアの１つであるＯｐｅｎＴＰ１の場合、ジャーナルスワップ、ジャーナルエディット等のコマンドを発行することによりユーザジャーナルを取得することができる。
【００１６】
ユーザシステム１０２は、ＳＡＭファイル１０５内のユーザジャーナル、発生した障害の内容に対応したエラーコード１０６、及び、ユーザシステムで取り扱う文字コード１０７をパラメータとして設定した呼出し要求を行って自動リカバリシステム１０８の呼出しを行う。
【００１７】
自動リカバリシステム１０８は、コード変換機能１０９、ジャーナル変換機能１１０、リカバリ対応ＤＢ検索機能１１１、リカバリ機能１１２の４つの処理部により構成され、また、レイアウト定義ＤＢ１１３、リカバリ対応ＤＢ１１４を備えている。レイアウト定義ＤＢ１１３、リカバリ対応ＤＢ１１４は、予め必要なデータが登録されており、ジャーナル変換機能１１０、リカバリ対応ＤＢ検索機能１１１により参照される。
【００１８】
自動リカバリシステム１０８は、コード変換機能１０９、ジャーナル変換機能１１０、リカバリ対応ＤＢ検索機能１１１、リカバリ機能１１２の４つの処理部が順に処理を実行して、障害の起因となった情報を修復する。リカバリされた情報は、ユーザシステム１０２に戻され、これにより、ユーザシステム１０２は、人手を介することなく自動的に障害の発生後の後続処理１１５を継続して実行することが可能となる。
【００１９】
図２はコード変換機能１０９の処理動作を説明するフローチャートであり、次に、これについて説明する。コード変換機能１０９は、ユーザジャーナル入力処理２０１、文字コード変換処理２０２、変換後データ出力処理２０３の３つの処理部から構成される。以下では、これらの３つの処理部での処理動作としてコード変換機能１０９の処理動作を説明する。
【００２０】
（１）ユーザジャーナル入力処理２０１は、ＳＡＭファイル２０４内のユーザジャーナル読込みを行い、変換前のユーザジャーナルのデータをプログラム内部のバッファメモリ上に展開する。
【００２１】
（２）次に、文字コード変換処理２０２は、入力ファイルの様々な種類の文字コードに対して、一律にＳＪＩＳコードへ変換処理を行う。変換前の文字コードについては、文字コード２０５のパラメータ（その構成については図１０を参照して後述する）に登録されているためそれに従う。
【００２２】
（３）次に、変換後データ出力処理２０３は、文字コード変換処理２０２がＳＪＩＳコードへ変換したユーザジャーナルデータをＳＡＭファイル２０６出力する。
【００２３】
図３はジャーナル変換機能１１０の処理動作を説明するフローチャートであり、次に、これについて説明する。ジャーナル変換機能１１０は、レイアウト定義の取得処理３０１、テキスト形式への変換処理３０２、変換後データ取得処理３０３の３つの処理部から構成される。以下では、これらの３つの処理部での処理動作としてジャーナル変換機能１１０の処理動作を説明する。
【００２４】
（１）レイアウト定義の取得処理３０１は、レイアウト定義ＤＢ（その構成については図６を参照して後述する）３０４からユーザジャーナルのレイアウト定義の情報を取得する。レイアウト定義ＤＢ３０４は、ユーザプログラムの実行環境毎に登録することが可能とされており、例えば、実行環境Ａで取得するユーザジャーナルのレイアウト定義を登録し、または、実行環境Ｂにて取得するユーザジャーナルのレイアウト定義を登録することが可能である。
【００２５】
（２）次に、テキスト形式への変換処理３０２は、ＳＡＭファイル３０５内の変換前のユーザジャーナルデータを入力として、レイアウト定義ＤＢ３０４内に登録されているレイアウト定義の情報の内、有効フラグがオンになっている方のレイアウト定義を参照し、それに従いテキスト形式への変換処理を実行する。ＳＡＭファイル３０５内のデータレコードは、図３（ａ）にユーザジャーナル３０７として示しているように、左側部が１６進数の形式、右側部が楕円で囲んで示しているようにテキスト形式で表示されており、４バイト区切りで空白部が存在していたり、１６バイトで改行が行われていたりするなど特異な形式で表示されている。そして、テキスト形式への変換処理３０２は、図３（ｂ）に前述の右側部のテキスト形式の変換前のデータを３０８として示すように取出し、定型の区切り空白部分と改行を除外して、入力情報をテキスト文字列形式へのと変換処理を行い、図３（ｃ）に３０９として示しているように、入力されたままの元データの復元を行う。
【００２６】
（３）次に、変換後データ出力処理３０３は、テキスト形式への変換処理３０２により変換された変換後のユーザジャーナルデータ３０９をＳＡＭファイル（その構成については図９を参照して後述する）３０６へ出力する。
【００２７】
図４はリカバリ対応ＤＢ検索機能１１１の処理動作を説明するフローチャートであり、次に、これについて説明する。リカバリ対応ＤＢ検索機能１１１は、リカバリ対応ＤＢ検索処理４０１、対応内容と対応要否の取得処理４０２の２つの処理部から構成される。以下では、これらの２つの処理部での処理動作としてリカバリ対応ＤＢ検索機能１１１の処理動作を説明する。
【００２８】
（１）リカバリ対応ＤＢ検索処理４０１は、エラーコード４０３のパラメータとして受け取ったエラーコード（その構成については図１０を参照して後述する）を使用し、リカバリ対応ＤＢ（その構成については図７を参照して後述する）４０４を検索する。リカバリ対応ＤＢ４０４には、予めエラーコードに対応したリカバリ方法が登録されている。
【００２９】
（２）対応内容と対応要否の取得処理４０２の処理は、リカバリ対応ＤＢ検索処理４０１が検索処理で取得したリカバリ処理の対応要否と対応内容の情報とをプログラム内部のバッファメモリ上に展開する。
【００３０】
図５はリカバリ機能１１２の処理動作を説明するフローチャートであり、次に、これについて説明する。リカバリ機能１１２は、対応要否の判断処理５０１、エラーのリカバリ処理５０２の２つの処理部から構成される。以下では、これらの２つの処理部での処理動作としてリカバリ機能１１２の処理動作を説明する。
【００３１】
（１）対応要否の判断処理５０１は、リカバリ対応ＤＢ検索処理４０１が検索処理で取得したリカバリ処理の対応要否と対応内容の情報とからリカバリ処理の対応の要否を判定し、リカバリ不要の場合、何の処理を行わずにここでの処理を終了する。
【００３２】
（２）リカバリ処理の対応の要否判断処理５０１の判定で、リカバリ要と判定した場合、リカバリ処理５０２は、元のデータへ変換された後のユーザジャーナルをＳＡＭファイル５０３から入力して、リカバリ対応ＤＢ４０４から取得した対応内容に従ってデータの補正を行う。リカバリ対応ＤＢ４０４には、補完データと補完ポイントとのバイト位置情報が予め登録されており、補完ポイントは、ユーザジャーナルデータの何バイト目から何バイト分のデータを補正するかを決定するために利用され、補完データは、そのポイントに対してデータの修復のためのデータである。
【００３３】
次に、対応内容の例について説明する。ＳＡＭファイル５０３のデータには、図５（ａ）に修正前のデータ５０５として示すように、５バイト目から４バイト（各バイトを△で示す）分が空白となっており、ユーザプログラムは、この空白となっている部分の必須項目が未入力と判断してエラーを検知した。
【００３４】
リカバリ対応ＤＢ４０４には、予め必須項目が未入力の場合を想定し、図５（ｂ）にリカバリ対応ＤＢの対応内容５０６として示すように、障害修復の対応内容として、未入力の場合、９９９９というデータで補完するように登録済である。前述した図５に示すフローでの処理の場合、修正前データ５０５の５バイト目から４バイトに９９９９が補完され、修正後のユーザジャーナルのデータは、図５（ｃ）に５０７として示すようなものに修正されることになる。
【００３５】
前述で説明したように、リカバリ処理５０２で修正されたユーザジャーナルデータは、ＳＡＭファイル５０４へ出力され、この修正後データは、引き続きユーザシステム１０２側で入力情報として取り込まれて後続処理を実行することができる。これにより、ユーザシステム１０２は、障害発生時に処理を中断することなく自動的に処理を継続することが可能となる。
【００３６】
図６はレイアウト定義ＤＢの構成を説明する図である。レイアウト定義ＤＢには、図６（ａ）に示すように、ユーザプログラムの実行環境毎に付与されるパターンＩＤと、テキスト形式の取得開始位置を示すテキスト開始位置と、連続で記載されている文字数を示す連続文字数と、テキスト形式の改行までの文字数を示す１行当りの文字数と、現在の実行環境に対してフラグがオンとされる有効フラグとが１組のデータとして、ユーザプログラムの実行環境毎に複数のデータの組がそれぞれ１つのレコードとして格納される。レイアウト定義ＤＢは、図６（ｂ）、図６（ｃ）に実行環境Ａ、Ｂの場合のデータ例として示しているようなデータを含むレコードがレイアウト定義として格納される場合、図６（ｄ）に示しているようなレコードとして保持することになる。
【００３７】
図７はリカバリ対応ＤＢの構成を説明する図である。リカバリ対応ＤＢには、図７（ａ）に示すように、ユーザプログラムから受け取ったエラーコードを示すエラーコードと、自動リカバリシステムでの対応の要否を示す対応要否と、補完するデータを示す補完データと、補完を行う開始位置を示す補完ポイントとが１組データとして、エラーコード毎に複数の組のそれぞれが１つのレコードとして格納される。そして、リカバリ対応ＤＢには、図７（ｂ）にデータ例として、エラーコードＸＸＸの必須項目が未入力、エラーコードＹＹＹの数字項目不正、エラーコードＺＺＺの区分値不正の場合のレコードの例として示しているようなレコードが格納されており、これらのレコードの場合、図７（ｃ）に示す修正前のデータが、図７（ｄ）に修正後のデータとして示すように修正されることになる。
【００３８】
図８はＳＡＭファイル内に保持されているユーザジャーナル（変換前）の構成を説明する図である。ＳＡＭファイルには、図８（ａ）に示すように、障害発生の起因となった入力データであるジャーナルファイルのデータのレコードであるジャーナルデータが１つのレコードとして、複数のレコードが格納されている。入力データが、図８（ｂ）にメインフレームからのユーザジャーナルの情報として示しているようなデータの場合、ＳＡＭファイル内には、図８（ｃ）に変換前のジャーナルデータとして示すようなデータとして格納される。
【００３９】
図９はＳＡＭファイル内に保持されているユーザジャーナル（変換後）の構成を説明する図である。ＳＡＭファイルには、図９（ａ）に示すように、障害発生の起因となった入力データであるジャーナルファイルのデータのレコードであるジャーナルデータが１つのレコードとして、複数のレコードが格納されている。入力データが、図８に示した変換前の場合と同様に、図９（ｂ）にメインフレームからのユーザジャーナルの情報として示しているようなデータの場合、ＳＡＭファイル内には、図９（ｃ）に変換後のジャーナルデータとして示すようなデータが格納される。
【００４０】
図１０はエラーコード、文字コードのパラメータの構成を説明する図である。エラーコードは、図１０（ａ）に示しているようなエラー内容を特定することができるコードであり、エラーコードのデータ例としては、必須項目が未入力の場合のエラーコードＸＸＸ、数字項目不正である場合のエラーコードＹＹＹ、区分値不正である場合のエラーコードＺＺＺ等のエラーコードがある。また、文字コードは、図１０（ｂ）に示しているような自動リカバリーシステム１０８で取り扱う文字コードであり、文字コードの例としては、データ例に０として示すＳＪＩＳ、データ例に１として示すＥＢＣＤＩＣ、データ例に２として示すＵＮＩＣＯＤＥ、データ例に３として示すＥＩＧ等がある。
【００４１】
前述した本発明の実施形態によれば、オープン系のコンピュータシステムにおいて、プログラム処理中に発生した障害に対する修復データを予め登録しておくこととし、プログラム処理中に障害が発生した場合、リカバリシステムが登録されている修復データを利用して機械的にデータ修復まで行うことができるため、人手と時間を必要とすることなく、障害を発生させたプログラムのリカバリ対応が可能となり、また、人為的判断ミスが無くなるため、回復作業誤りによる二次災害のリスクを抑止することができる。
【符号の説明】
【００４２】
１０１ サーバマシン
１０２ ユーザシステム
１０３ 障害検知手段
１０４ 自動リカバリシステム呼出し手段１０４
１０５ ＳＡＭファイル
１０８ 自動リカバリシステム
１０９ コード変換機能
１１０ ジャーナル変換機能
１１１ リカバリ対応ＤＢ検索機能
１１２ リカバリ機能
１１３ レイアウト定義ＤＢ
１１４ リカバリ対応ＤＢ
【特許請求の範囲】
【請求項１】
ユーザシステムと、該ユーザシステムに障害が発生した場合に、障害の原因を特定して障害を回復させるリカバリシステムとにより構成されるコンピュータシステムにおいて、
前記リカバリシステムは、前記ユーザシステムから受け取ったエラーコード、リカバリシステムでの対応の要否を示す対応要否、補完するデータを示す補完データを格納しているリカバリ対応ＤＢと、該リカバリ対応ＤＢを検索するリカバリ対応ＤＢ検索手段と、リカバリ手段とを備え、
前記ユーザシステムに障害が発生したとき、前記ユーザシステムから起動され、前記ユーザシステムから送られてきた障害発生時の入力データ及びエラーコードを受取り、前記リカバリ対応ＤＢ検索手段が、前記リカバリ対応ＤＢを検索し、対応要否が対応要を示していた場合、障害発生時の障害内容に対応する補完データを取得し、前記リカバリ手段が、前記ユーザシステムから送られてきた障害発生時の入力データの修復を行い、前記ユーザシステムに、修復したデータを送信し、障害発生の以後の後続処理を続けさせることを特徴とするコンピュータシステム。
【請求項２】
前記リカバリシステムは、前記ユーザシステムから送られてきた障害発生時の入力データに対するコード変換手段を備え、該コード変換手段は、前記ユーザシステムで使用している文字コードを自リカバリシステムで使用する文字コードに変換することを特徴とする請求項１記載のコンピュータシステム。
【請求項３】
前記ユーザシステムから送られてきた障害発生時の入力データは、ユーザジャーナルであり、
前記リカバリシステムは、ジャーナル変換手段をさらに備え、該ジャーナル変換手段が、前記ユーザジャーナルをテキスト形式に変換することを特徴とする請求項２記載のコンピュータシステム。
【請求項４】
ユーザシステムと、該ユーザシステムに障害が発生した場合に、障害の原因を特定して障害を回復させるリカバリシステムとにより構成されるコンピュータシステムにおける障害に対するリカバリ方法において、
前記リカバリシステムは、前記ユーザシステムから受け取ったエラーコード、リカバリシステムでの対応の要否を示す対応要否、補完するデータを示す補完データを格納しているリカバリ対応ＤＢと、該リカバリ対応ＤＢを検索するリカバリ対応ＤＢ検索手段と、リカバリ手段とを備え、
前記ユーザシステムに障害が発生したとき、前記ユーザシステムから起動され、前記ユーザシステムから送られてきた障害発生時の入力データ及びエラーコードを受取り、前記リカバリ対応ＤＢ検索手段が、前記リカバリ対応ＤＢを検索し、対応要否が対応要を示していた場合、障害発生時の障害内容に対応する補完データを取得し、前記リカバリ手段が、前記ユーザシステムから送られてきた障害発生時の入力データの修復を行い、前記ユーザシステムに、修復したデータを送信し、障害発生の以後の後続処理を続けさせることを特徴とするリカバリ方法。
【請求項１】
ユーザシステムと、該ユーザシステムに障害が発生した場合に、障害の原因を特定して障害を回復させるリカバリシステムとにより構成されるコンピュータシステムにおいて、
前記リカバリシステムは、前記ユーザシステムから受け取ったエラーコード、リカバリシステムでの対応の要否を示す対応要否、補完するデータを示す補完データを格納しているリカバリ対応ＤＢと、該リカバリ対応ＤＢを検索するリカバリ対応ＤＢ検索手段と、リカバリ手段とを備え、
前記ユーザシステムに障害が発生したとき、前記ユーザシステムから起動され、前記ユーザシステムから送られてきた障害発生時の入力データ及びエラーコードを受取り、前記リカバリ対応ＤＢ検索手段が、前記リカバリ対応ＤＢを検索し、対応要否が対応要を示していた場合、障害発生時の障害内容に対応する補完データを取得し、前記リカバリ手段が、前記ユーザシステムから送られてきた障害発生時の入力データの修復を行い、前記ユーザシステムに、修復したデータを送信し、障害発生の以後の後続処理を続けさせることを特徴とするコンピュータシステム。
【請求項２】
前記リカバリシステムは、前記ユーザシステムから送られてきた障害発生時の入力データに対するコード変換手段を備え、該コード変換手段は、前記ユーザシステムで使用している文字コードを自リカバリシステムで使用する文字コードに変換することを特徴とする請求項１記載のコンピュータシステム。
【請求項３】
前記ユーザシステムから送られてきた障害発生時の入力データは、ユーザジャーナルであり、
前記リカバリシステムは、ジャーナル変換手段をさらに備え、該ジャーナル変換手段が、前記ユーザジャーナルをテキスト形式に変換することを特徴とする請求項２記載のコンピュータシステム。
【請求項４】
ユーザシステムと、該ユーザシステムに障害が発生した場合に、障害の原因を特定して障害を回復させるリカバリシステムとにより構成されるコンピュータシステムにおける障害に対するリカバリ方法において、
前記リカバリシステムは、前記ユーザシステムから受け取ったエラーコード、リカバリシステムでの対応の要否を示す対応要否、補完するデータを示す補完データを格納しているリカバリ対応ＤＢと、該リカバリ対応ＤＢを検索するリカバリ対応ＤＢ検索手段と、リカバリ手段とを備え、
前記ユーザシステムに障害が発生したとき、前記ユーザシステムから起動され、前記ユーザシステムから送られてきた障害発生時の入力データ及びエラーコードを受取り、前記リカバリ対応ＤＢ検索手段が、前記リカバリ対応ＤＢを検索し、対応要否が対応要を示していた場合、障害発生時の障害内容に対応する補完データを取得し、前記リカバリ手段が、前記ユーザシステムから送られてきた障害発生時の入力データの修復を行い、前記ユーザシステムに、修復したデータを送信し、障害発生の以後の後続処理を続けさせることを特徴とするリカバリ方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１３−１０１５４８（Ｐ２０１３−１０１５４８Ａ）
【公開日】平成２５年５月２３日（２０１３．５．２３）
【国際特許分類】
【出願番号】特願２０１１−２４５６２０（Ｐ２０１１−２４５６２０）
【出願日】平成２３年１１月９日（２０１１．１１．９）
【出願人】（０００２３３４９１）株式会社日立システムズ (394)
【Ｆターム（参考）】
【公開日】平成２５年５月２３日（２０１３．５．２３）
【国際特許分類】
【出願日】平成２３年１１月９日（２０１１．１１．９）
【出願人】（０００２３３４９１）株式会社日立システムズ (394)
【Ｆターム（参考）】
[ Back to top ]