(57)【特許請求の範囲】
【請求項１】
複数のプログラムを搭載した装置におけるシステム自動再立ち上げ制御方法において、
各プログラム毎にエラー発生時の再起動レベルと所定の再起動回数とを記憶するプライオリティ記憶手段と、
プログラム実行時におけるエラーの発生を検知するエラー発生検知手段と、
プログラム毎に再起動実施回数を記録するプログラムエラー管理手段とを有し、
前記エラー発生検知手段により第１プログラムのエラーの発生が検知されたとき、前記第１プログラムについて前記プライオリティ記憶手段の再起動レベルとして記憶されているオペレーティングシステム（ＯＳ）を含めてシステムを再起動するレベル、自身のプログラムのみを再起動するレベル、自身のプログラムのみを終了するレベルに基づき、ＯＳを含めてシステムを再起動するレベルおよび自身のプログラムのみを再起動するレベルであるときに前記第１プログラムの再起動を要と判別し、
前記第１プログラムの再起動が要と判別されたとき、前記第１プログラムについて前記プログラムエラー管理手段の再起動実施回数を更新し、
前記第１プログラムについて、前記プライオリティ記憶手段の所定の再起動回数と前記プログラムエラー管理手段の再起動実施回数とを比較し、
再起動実施回数が所定の再起動回数以下のとき、前記第１プログラムを再起動することを特徴とするシステム自動再立ち上げ制御方法。
【請求項２】
搭載した複数のプログラムの自動再立ち上げを制御する自動再立ち上げ制御システムにおいて、
プログラム毎にエラー発生時の再起動レベルと所定の再起動回数とを記憶するプライオリティ記憶手段と、
プログラム実行時におけるエラーの発生を検知するエラー発生検知手段と、
プログラム毎に再起動実施回数を記録するプログラムエラー管理手段と、
前記エラー発生検知手段によりプログラムのエラーを検知したとき、前記プライオリティ記憶手段の再起動レベルとして記憶されているオペレーティングシステム（ＯＳ）を含めてシステムを再起動するレベル、自身のプログラムのみを再起動するレベル、自身のプログラムのみを終了するレベルに基づき、ＯＳを含めてシステムを再起動するレベルおよび自身のプログラムのみを再起動するレベルであるときに当該プログラムの再起動を要と判別する手段と、
前記エラー発生検知手段でエラーを検知したプログラムについて、再起動を要と判別したとき、前記プログラムエラー管理手段の再起動実施回数を更新する手段と、
前記エラー発生検知手段でエラーを検知したプログラムについて、前記プライオリティ記憶手段の所定の再起動回数と前記プログラムエラー管理手段の再起動実施回数とを比較する手段と、
前記エラー発生検知手段でエラーを検知したプログラムの再起動が要で且つ前記再起動実施回数が前記所定の再起動回数以下のとき、当該プログラムを再起動する手段とを有することを特徴とするシステム自動再立ち上げ制御システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、複数のプログラム（業務アプリケーションなど）を搭載した装置のシステム自動再立ち上げ制御方法およびシステム自動再立ち上げシステムに関し、特に、装置全体がハングアップすることなく、以降のシステムの処理をできるだけ継続することを可能にしたシステム自動再立ち上げ制御方法およびシステム自動再立ち上げ制御システムに関する。
【０００２】
【従来の技術】
従来の技術として、「特開昭５６−４８４８号公報」のように装置外部にチェック手段、および、カウンタを設けることにより当該装置の再起動を実現していた。また、「特開昭５６−１２７２５６号公報」のようにアプリケーション実行時の障害を検知する技術や「特開平５−２３３３４１号公報」においては、アプリケーション障害検知後の再起動を無限に繰り返さない公知技術はあるが、一装置内でのアプリケーション障害検知に対して、そのアプリケーションの再起動要／否のプライオリティレベルでの自動判定により、再起動する一連の流れの方式については、考慮されていなかった。
【０００３】
【発明が解決しようとする課題】
前記従来の技術は、外部装置により業務アプリケーションエラー検知を行っており、また、業務アプリケーションの重要性について配慮されておらず、業務アプリケーションエラーを検知後、無条件に再起動を行っていた。
本発明は、装置内でプログラムのエラー検知を行い、プログラムエラー検知時に、自動的にエラーの発生したプログラムのレベルに応じてプログラムの再起動またはプログラムの終了を実行するようにして、装置（システム）全体がハングアップすることなく、以降のシステムの処理をできるだけ継続することを目的としている。
【０００４】
【課題を解決するための手段】
本発明は、上記目的を達成するために、装置に搭載しているプログラム毎にエラー発生時の再起動レベルをプライオリティ記憶手段（プライオリティテーブル１３）に登録しておく。そして、プログラム実行時にエラー発生検知手段（アプリケーションエラー検知プロセス１０）によりエラーの発生を検知すると、プライオリティ記憶手段を参照してエラーの発生が検知されたプログラムに対する再起動レベルを判別し、その再起動レベルに基づいてシステムを再起動する。再起動レベルとしては、オペレーティングシステム（ＯＳ）を含めて再起動するか、自身のプログラムだけを再起動するか、または自身のプログラムを終了するかなどを規定するレベルなどが考えられる。
この構成を採用することにより、プログラムの重要性に応じた再起動レベルを設定しておき、その内容に応じて最適なシステムの自動再立ち上げやプログラムの終了を行うことができ、結果的に、システムに不必要なハングアップを生じさせることなく以降の処理を継続させることが可能になる。
【０００５】
【発明の実施の形態】
以下、本発明の実施例を説明する。なお、本発明は、全てのプログラム（ソフトウェア）に適用できるが、以下の説明では、プログラムとして業務アプリケーションを中心にして説明する。
（第１の実施例）
まず、本発明の第１の実施例を、図１〜図７を用いて説明する。
本実施例は、本発明を現金自動取引装置の各種業務アプリケーションに適用したもので、図１は本実施例のシステム構成図、図２は本実施例のソフトウェア構成図、図３はプライオリティテーブルの構造例、図４はアプリケーションエラー管理テーブルの構造例、図５〜図７は本実施例に係るシステム自動再立ち上げ制御の流れを説明するための図である。
【０００６】
図１は、一般的な銀行内システムの構成を示している。
同図において、１はセンタ側構成である勘定系ホスト、２はＩＳＤＮ（Ｉntegrated Ｓervices Ｄigital Ｎetwork）、３はルータ、４は営業店側構成である営業店サーバ（中継サーバ）、５は営業店端末、６Ａ〜６Ｂは現金自動取引装置である。
【０００７】
勘定系ホストシステム（１）は、営業店端末（５）や現金自動取引装置（６Ａ〜６Ｂ）でエンドユーザによって行われる各種取引の勘定処理、営業店端末（５）や現金自動取引装置（６Ａ〜６Ｂ）に対しての出金または印字などの指示を行うためのホストシステムである。営業店サーバ（４）は、各営業店端末（５）や現金自動取引装置（６Ａ〜６Ｂ）がそれぞれ勝手にホストシステム（１）に対して電文送信を行った場合、ホストシステム（１）側での管理／処理が困難になるため、営業店内の各装置を統括し、ルータ（３）を介してホストシステムに情報を送受信するための中継サーバである。これにより、ホストシステム（１）は、通信する装置として営業店サーバ（４）単位で管理することとなる。
【０００８】
図２は、本実施例における現金自動取引装置（６Ａ〜６Ｂ）のソフトウェア構成例を示す図である。
ソフトウェア構成としては、装置を動作させるための基本ソフトであるオペレーティングシステム（１５）と、アプリケーションエラー検知および再起動要否を判定するためのアプリケーションエラー検知プロセス（１０）および再起動要否判定プロセス（１１）を含むミドルソフトウェア群（９）と、現金自動取引装置（６Ａ〜６Ｂ）で行われる各種取引を処理する業務アプリケーション群（８Ａ〜８Ｂ）と、その他の流通ソフトウェア群（７Ａ〜７Ｂ）と、再起動判定に必要であるプライオリティテーブル（１３）と、アプリケーションエラー検知時にエラー内容を登録しておくロギングファイル（１２）と、アプリケーションエラーが発生した際のエラー回数や再起動回数を保持しておくためのアプリケーションエラー管理テーブル（１４）とから構成される。
【０００９】
図３は、プライオリティテーブル（１３）の構造例を示す図である。
同図に示すように、プライオリティテーブル（１３）は、監視対象となるアプリケーション名称を登録する「アプリケーション名称」（１６）と、アプリケーションエラー検知およびハングアップ検知対象となる主プロセス名称を登録する「プロセス名称」（１７）と、再起動を行う際の実施レベル（ＯＳを含めて再起動を行うまたは自身の業務アプリケーションのみを再起動するなどのレベル）を登録する「再起動レベル」（１８）と、再起動を行う際、永久ループに陥ることを防止するために登録する「再起動回数」（１９）とから構成される。
【００１０】
また、本プライオリティテーブル（１３）の最初の欄「Ｎｏ．０」（２０）の設定内容は、全アプリケーションを対象としたエリアとして位置付ける。全アプリケーション対象エリアの再起動レベル（２１）の設定値は「０」（各業務アプリケーションの設定値を有効にする）と「１」（アプリケーションエラーを検知したら無条件にＯＳを含めて再起動する）の２通りの設定方法を設ける。図３の場合は再起動レベルが「０」、再起動回数が「３」の場合を示している。
【００１１】
また、各業務アプリケーション対象エリアの再起動レベル（２２）の設定値として「Ａ」「Ｂ」「Ｃ」の３通りの設定方法を設ける。ここで、「Ａ」は“ＯＳを含めて再起動する”を意味し、「Ｂ」は“自身の業務アプリケーションのみを終了する”を意味し、「Ｃ」は、“自身の業務アプリケーションのみを再起動する”を意味する。
【００１２】
図４は、アプリケーションエラー管理テーブル（１４）の構造例を示す図である。
同図に示すように、アプリケーションエラー管理テーブル（１４）は、監視対象となるアプリケーション名称を登録する「アプリケーション名称」（１６）（本名称はプライオリティテーブル（１３）に登録することで自動的に反映される）と、アプリケーションエラーの発生した回数を管理する「エラー発生回数」（２４）と、再起動を行った回数を保持する「再起動実施回数」（２５）とから構成される。
【００１３】
全業務アプリケーション対象および各業務アプリケーション対象の再起動レベルが再起動実施要の設定がされている場合は、再起動処理を行う都度、図４のアプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）を＋１づつ更新する。「再起動回数」（１９）に設定されている回数分再起動処理を行った後に再度アプリケーションエラーを検知した場合は、保守員によるエラー要因除去などが必要な旨のメッセージを表示するとともに監視システムに対しても通知を行う。
【００１４】
図５は、自身の業務アプリケーションのみを終了する場合のシステム自動再立ち上げの例を示す図である。はじめに各プロセスの機能分担を説明する。
同図において、業務アプリケーション２（２６）は現金自動取引装置（６Ａ〜６Ｂ）で動作するアプリケーションでプライオリティテーブル（１３）の再起動レベルが「Ｂ」を有しており、該アプリケーションのみを終了しても現金自動取引装置（６Ａ〜６Ｂ）全体としての機能に特に弊害を与えないアプリケーションである（例えば、現金自動取引装置において、入金取引を処理するアプリケーションを終了しても、出金その他の取引に影響はない）。
【００１５】
システム管理プロセス（２７）は、再起動要否判定プロセス（２９）から通知された処理内容やエラー内容をロギングファイル（１２）に取得し、各アプリケーションへの終了指示、システムの再起動などの処理を行う。アプリケーションエラー検知プロセス（２８）は、プライオリティテーブル（１３）に登録されているアプリケーションの状態を監視するプロセスである。再起動要否判定プロセス（２９）は、アプリケーションエラー検知プロセス（２８）から通知される「アプリケーションエラー発生通知」により再起動を行うか否かをプライオリティテーブル（１３）を参照して判定し、判定した結果をシステム管理プロセス（２７）に通知するプロセスである。
【００１６】
本例において、プライオリティテーブル（１３）の再起動レベル（１８）が「Ｂ（自身の業務アプリケーションのみを終了する）」と設定されている業務アプリケーション２（２６）でアプリケーションエラーが発生し（ステップ３０）、そのエラーをアプリケーションエラー検知プロセス（２８）が検知する（ステップ３１）。アプリケーションエラー検知プロセス（２８）は、エラーの発生したアプリケーション名称などを再起動要否判定プロセス（２９）に通知する（ステップ３２）。エラー通知を受信した再起動要否判定プロセス（２９）は、プライオリティテーブル（１３）をサーチし、処理を判定する（ステップ３３）。再起動要否判定プロセス（２９）は、判定した結果をシステム管理プロセス（２７）に「アプリケーション終了指示」として通知する（ステップ３４）。
【００１７】
指示を受信したシステム管理プロセス（２７）は、アプリケーションエラーの発生した業務アプリケーション名称、エラー発生内容などをロギングデータ取得処理（ステップ３５）にてロギングファイル（１２）に取得後（ステップ３６）、アプリケーションの終了処理を行う（ステップ３７，ステップ３８）。その結果、エラーの発生した業務アプリケーションのみを終了し（ステップ３９）、一連の流れを完了する。
【００１８】
図６は、自身の業務アプリケーションのみを再起動する場合のシステム自動再立ち上げの例を示す図である。
本例において、流通ソフトウェア２（４０）は、インターネットなどを通じて各種情報を現金自動取引装置（６Ａ〜６Ｂ）に表示するためのアプリケーションでプライオリティテーブル（１３）の再起動レベルが「Ｃ」を有しており、例えば当該サービスだけを運用している時間帯（深夜など）にエラーが発生した場合は、現金自動取引装置（６Ａ〜６Ｂ）として何もサービスの提供ができなくなるため当該アプリケーションを再起動し、サービスを提供できる状態にする。その他の各プロセスの機能分担については、図５で説明した内容と同じである。
【００１９】
本例では、プライオリティテーブル（１３）の再起動レベルが「Ｃ（自身の業務アプリケーションのみを再起動する）」と設定されている流通ソフトウェア２（４０）でアプリケーションエラーが発生し（ステップ３０）、その発生したエラーをアプリケーションエラー検知プロセス（２８）が検知する（ステップ３１）。尚、業務アプリケーション２（２６）は、正常に動作している状態である。
【００２０】
アプリケーションエラー検知プロセス（２８）は、エラーの発生したアプリケーション名称などを再起動要否判定プロセス（２９）に通知する（ステップ３２）。エラー通知を受信した再起動要否判定プロセス（２９）は、プライオリティテーブル（１３）をサーチし、処理を判定する（ステップ３３）。本例では、再起動レベルが「Ｃ」すなわち自身のアプリケーションのみを再起動すると設定されているため、まず、アプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）を＋１更新処理（ステップ４１）して再格納する（ステップ４２）。
【００２１】
次に、プライオリティテーブル（１３）に設定されている再起動回数（１９）とアプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）を比較し（ステップ４３）、再起動実施回数（２５）が再起動回数（１９）以下の場合、システム管理プロセス（２７）に対してアプリケーション再起動指示を通知する（ステップ４４）。指示を受信したシステム管理プロセス（２７）は、アプリケーションエラーの発生した業務アプリケーション名称、エラー発生内容などをロギングデータ取得処理（ステップ３５）にてロギングファイル（１２）に取得後（ステップ３６）、アプリケーションの終了処理（ステップ３７，ステップ３８）を行った後、アプリケーションの再起動処理（ステップ４５）にてアプリケーションを再起動する。その結果、業務アプリケーションが再起動され（ステップ４７）、一連の流れを完了する。
【００２２】
また、プライオリティテーブル（１３）に設定されている再起動回数（１９）とアプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）を比較した結果（ステップ４３）、再起動実施回数（２５）の方が再起動回数（１９）より多い場合は、システム管理プロセス（２７）に対してアプリケーション終了指示を通知する（ステップ３４）。指示を受信したシステム管理プロセス（２７）は、アプリケーションエラーの発生した業務アプリケーション名称、エラー発生内容などをロギングデータ取得処理（ステップ３５）にてロギングファイル（１２）に取得した後（ステップ３６）、アプリケーションの終了処理を行う（ステップ３７，ステップ３８）。その結果、エラーの発生した業務アプリケーションのみを終了する（ステップ３９）。
【００２３】
尚、アプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）については、保守員などによるオペレーションにより“０クリア”を可能とする。また、前記のように再起動実施回数を超えるような場合は、保守員などによるエラー要因除去などの作業が必要な旨のメッセージを表示する。
【００２４】
図７は、ＯＳを含めて再起動する場合のシステム自動再立ち上げの例を示す図である。
業務アプリケーション１（４８）は、業務アプリケーション群とミドルソフトウェア郡とを連携するための重要なアプリケーションでプライオリティテーブル（１３）の再起動レベルが「Ａ」を有しており、当該アプリケーションにエラーが発生した場合、現金自動取引装置（６Ａ〜６Ｂ）としての動作が不安定となり、各種取引に影響が出る恐れがある。その他の各プロセスの機能分担については、図５で説明した内容と同じである。
【００２５】
本例では、プライオリティテーブル（１３）で「Ａ（ＯＳを含めて再起動する）」と設定されている業務アプリケーション１（４８）でアプリケーションエラーが発生し（ステップ３０）、そのエラーをアプリケーションエラー検知プロセス（２８）が検知する（ステップ３１）。尚、業務アプリケーション２（２６）は、正常に動作している状態である。エラーの発生したアプリケーション名称などを再起動要否判定プロセス（２９）に通知する（ステップ３２）。エラー通知を受信した再起動要否判定プロセス２９は、プライオリティテーブル（１３）をサーチし、処理を判定する（ステップ３３）。本例では、プライオリティテーブル（１３）の再起動レベル（１８）が「Ａ」でありＯＳを含めて再起動すると設定されているため、まずアプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）を＋１更新処理（ステップ４１）してアプリケーションエラー管理テーブル（１４）への格納を行う（ステップ４２）。
【００２６】
次に、プライオリティテーブル（１３）に設定されている再起動回数（１９）とアプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）をし比較（ステップ４３）、再起動実施回数（２５）が再起動回数以下の場合、システム管理プロセス（２７）に対してシステム再起動指示を通知する（ステップ４９）。指示を受信したシステム管理プロセス（２７）は、アプリケーションエラーの発生した業務アプリケーション名称、エラー発生内容などをロギングデータ取得処理にてロギングファイル（１２）に取得した後（ステップ３６）、自身のシステム終了処理（ステップ５０）および各アプリケーション終了処理（ステップ３７，ステップ３８）にて全業務アプリケーションを終了する（ステップ３９）。その後、システム自身が再起動され（ステップ５１）、各業務アプリケーションも開始され（ステップ５２）、一連の流れを完了する。
【００２７】
また、プライオリティテーブル（１３）に設定されている再起動回数（１９）とアプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）を比較した結果（ステップ４３）、再起動実施回数（２５）の方が再起動回数（１９）より多い場合は、システム管理プロセス（２７）に対してアプリケーション終了指示を通知する（ステップ３４）。指示を受信したシステム管理プロセス（２７）は、アプリケーションエラーの発生した業務アプリケーション名称、エラー発生内容などをロギングデータ取得処理にてロギングファイル（１２）に取得後（ステップ３６）、アプリケーションの終了処理を行う（ステップ３７，ステップ３８）。その結果、エラーの発生した業務アプリケーションのみを終了する（ステップ３９）。
【００２８】
尚、アプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）については、保守員などによるオペレーションにより“０クリア”を可能とする。また、上記のように再起動実施回数を超えるような場合は、保守員などによるエラー要因除去などの作業が必要な旨のメッセージを表示する。
【００２９】
次に、本発明の第２の実施例について説明する。本実施例は、本発明をワープロソフトや表計算ソフトなどの業務アプリケーションに適用したものである。
図８は本実施例のシステム構成図であり、図９は本発明のソフトウェア構成図であり、図１０はプライオリティテーブルの構造例を表し、図１１はアプリケーションエラー管理テーブルの構造例を示している。第１の実施例と同様のものには同一の符号を付与している。
【００３０】
図８において、１Ａ〜１Ｂは監視センタ側構成である監視サーバ、２はＩＳＤＮ、３Ａと３Ｂはルータ、６Ａ〜６Ｃは現金自動取引装置、２Ａ〜２Ｂは監視クライアント、５０は支店監視装置である。
【００３１】
監視サーバ（１Ａ〜１Ｂ）および監視クライアント（２Ａ〜２Ｂ）は、早朝・夜間および休日等営業店が無人となる時間帯における現金自動取引装置（６Ａ〜６Ｃ）の稼働状況を監視するシステムである。支店監視装置（５０）は、営業店が有人となる時間帯において営業店行員で現金自動取引装置（６Ａ〜６Ｃ）の稼働状況を監視するための装置であり、また、営業店が無人となる時間帯においては、現金自動取引装置（６Ａ〜６Ｃ）の障害情報をルータ（３Ａ〜３Ｂ）を介してセンタ側システムに情報を送信する機能を有する。
【００３２】
図９は、支店監視装置（５０）のソフトウェア構成図であり、装置を動作させるためのオペレーティングシステム（１５）と、アプリケーションエラー検知のためのアプリケーションエラー検知プロセス（１０）と、再起動要否を判定するための再起動要否判定プロセス（１１）と、現金自動取引装置の稼働状況を監視する業務アプリケーション（８Ａ）と、その他の業務アプリケーション群（８Ｂ〜８ｎ）と、再起動判定に必要であるプライオリティテーブル（１３）と、アプリケーションエラー検知時にエラー内容を登録しておくロギングファイル（１２）と、アプリケーションエラーが発生した際のエラー回数および再起動回数を保持しておくためのアプリケーションエラー管理テーブル（１４）とから構成される。
【００３３】
図１０は、本実施例におけるプライオリティテーブル（１３）の構造例を示す図である。
本実施例におけるプライオリティテーブル（１３）は、同図に示すように、監視対象となる業務アプリケーション名称（１６）と、アプリケーションエラー検知およびハングアップ検知対象となる主プロセス名称（１７）と、再起動を行う際の再起動レベル（１８）（ＯＳを含めて再起動を行うのか自身の業務アプリケーションのみを再起動するのかなどを指定する再起動レベル）と、再起動を行う際、永久ループに陥ることを防止するために登録する再起動回数（１９）から構成される。また、最初の項目である「Ｎｏ．０」（２０）については、全業務アプリケーションを対象として設定するエリアとして位置付ける。
【００３４】
プライオリティテーブル（１３）において、全業務アプリケーション対象エリアの再起動レベル（１８）の設定値は「０」（各業務アプリケーションの設定値を有効にする）と「１」（アプリケーションエラーを検知したら無条件にＯＳを含めて再起動する）の２通りの設定方法を設ける。また、各業務アプリケーション対象エリアの再起動レベル（１８）の設定値は、「Ａ」（ＯＳを含めて再起動する）、「Ｂ」（自身の業務アプリケーションのみを終了する）、「Ｃ」（自身の業務アプリケーションのみを再起動する）の３通りの設定方法を設ける。
【００３５】
図１０の例では、業務アプリケーション名称が「監視機能」の再起動レベル（１８）が「Ａ」、オペレータにより操作され報告書などを作成するためのアプリケーション「ワープロ」の再起動レベル（１８）が「Ｂ」、オペレータにより操作され見積書などを作成するためのアプリケーション「表計算」の再起動レベル（１８）が「Ｃ」に設定されている。
【００３６】
図１１は、アプリケーションエラー管理テーブル（１４）の構造例を示す図である。
アプリケーションエラー管理テーブル（１４）は、同図に示すように、監視対象となる業務アプリケーション名称（１６）と、アプリケーションエラーの発生した回数（２４）と再起動を行った回数を保持する再起動実施回数（２５）と含んでいる。
【００３７】
尚、プライオリティテーブル（１３）において、全業務アプリケーション対象エリアの再起動レベルが「１」で、各業務アプリケーション対象エリアの再起動レベルが「Ａ」と設定されている場合（今の例では「監視機能」）は、再起動処理を行う都度、図１１のアプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）を＋１づつ更新する。設定されている回数分再起動処理を行った後で再度アプリケーションエラーを検知した場合は、保守員によるエラー要因除去等が必要な旨のメッセージを表示する。
【００３８】
図１０および図１１の設定において、業務アプリケーション（ワープロ）でエラーが発生した場合には、プライオリティテーブル（１３）の再起動レベル（１８）が「Ｂ」であるので、図５で説明したのと同様の流れにより自身の業務アプリケーション（ワープロ）のみを終了する。ただし、図５において「業務アプリケーション２（２６）」を「業務アプリケーション（ワープロ）（２６）」に変更した流れになる。
【００３９】
また、業務アプリケーション（表計算）でエラーが発生した場合には、プライオリティテーブル（１３）の再起動レベル（１８）が「Ｃ」であるので、図６で説明したのと同様の流れにより自身の業務アプリケーション（表計算）のみを再起動する。この場合、例えば、図６において「業務アプリケーション２（２６）」を「業務アプリケーション（ワープロ）（２６）」に、「流通ソフトウェア２（４０）」を「業務アプリケーション（表計算）（４０）」に変更した流れになる。
【００４０】
さらに、監視機能でエラーが発生した場合には、プライオリティテーブル（１３）の再起動レベル（１８）が「Ａ」であるので、図７で説明したのと同様の流れによりＯＳを含めて再起動する。この場合、例えば、図６において「業務アプリケーション２（２６）」を「業務アプリケーション（ワープロ）（２６）」に、「業務アプリケーション１（４８）」を「業務アプリケーション（監視機能）（４８）」に変更した流れになる。
【００４１】
以上述べたように、本実施例によれば、業務アプリケーションごとに再起動レベルを設定しておくことにより、ある業務アプリケーションにエラーが発生した場合に、エラーを発生した当該業務アプリケーションの設定されている再起動レベルに応じて、自動的に再起動，終了など行うようにし、システム全体をハングアップさせることなく業務を継続することができる。
【００４２】
【発明の効果】
本発明によれば、無人運用を行っている装置で業務アプリケーションエラーが発生した場合でも装置自身で再立ち上げまたは当該業務アプリケーションのみの終了を判定し、処理することでエラー発生後もハングアップすることなく継続して業務を行うことが可能になり、従来、無人運用を行っている装置で業務アプリケーションエラーが発生した場合、エラーが発生した時点でシステムがハングアップしてしまい、以降の業務を継続することができなかったという問題を解消できる。
【図面の簡単な説明】
【図１】本発明を適用する第１の実施例のシステム構成図である。
【図２】本発明の第１の実施例に係るソフトウェア構成図である。
【図３】本発明の第１の実施例に係るプライオリティテーブルの構造図である。
【図４】本発明の第１の実施例に係るアプリケーションエラー管理テーブルの構造図である。
【図５】本発明の第１の実施例に係るシステム自動再立ち上げの流れを説明するための図である（自身の業務アプリケーションのみを終了する場合）。
【図６】本発明の第１の実施例に係るシステム自動再立ち上げの流れを説明するための図である（自身の業務アプリケーションのみを再起動する場合）。
【図７】本発明の第１の実施例に係るシステム自動再立ち上げの流れを説明するための図である（ＯＳを含めて再起動する場合）。
【図８】本発明を適用する第２の実施例のシステム構成図である。
【図９】本発明の第２の実施例に係るソフトウェア構成図である。
【図１０】本発明の第２の実施例に係るプライオリティテーブルの構造図である。
【図１１】本発明の第２の実施例に係るアプリケーションエラー管理テーブルの構造図である。
【符号の説明】
１…勘定系ホスト（ホストシステム）、
１Ａ〜１Ｂ…監視サーバ、
２…ＩＳＤＮ、
２Ａ〜２Ｂ…監視クライアント、
３，３Ａ，３Ｂ…ルータ、
４…営業店サーバ、
５…営業店端末、
６Ａ〜６Ｃ…現金自動取引装置、
７Ａ〜７Ｂ…流通ソフトウェア、
８Ａ〜８ｎ…業務アプリケーション、
９…ミドルソフトウェア群、
１０…アプリケーションエラー検知プロセス、
１１…再起動要否判定プロセス、
１２…ロギングファイル、
１３…プライオリティテーブル、
１４…アプリケーションエラー管理テーブル、
１５…オペレーティングシステム（ＯＳ）、
５０…支店監視装置。
【図１】
0003711789.tif 000002
【図２】
0003711789.tif 000003
【図３】
0003711789.tif 000004
【図４】
0003711789.tif 000005
【図５】
0003711789.tif 000006
【図６】
0003711789.tif 000007
【図７】
0003711789.tif 000008
【図８】
0003711789.tif 000009
【図９】
0003711789.tif 000010
【図１０】
0003711789.tif 000011
【図１１】
0003711789.tif 000012