JP2000347759A - システム自動再立ち上げ制御方式 - Google Patents

Abstract

(57)【要約】 【課題】 装置内でプログラムのエラー検知を行い、プ
ログラムエラー検知時に、自動的にエラーの発生したプ
ログラムのレベルに応じてプログラムの再起動またはプ
ログラムの終了を実行するようにして、装置（システ
ム）全体がハングアップすることなく、以降のシステム
の処理をできるだけ継続すること。 【解決手段】 プログラム（業務アプリケーション８Ａ
〜８Ｂなど）のエラー発生を検知するプロセス１０と、
プライオリティレベルを登録したプライオリティテーブ
ル１３と、プライオリティテーブルを元にシステムの再
立ち上げおよびエラー発生業務アプリケーションの終了
を判定するプロセス１１を設けることにより、プログラ
ムで障害が発生した場合でもシステムがハングアップす
ることなく、以降プライオリティレベルに応じて業務を
継続して行うことが可能となる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数のプログラム
（業務アプリケーションなど）を搭載した装置のシステ
ム自動再立ち上げ制御方式に関し、特に、装置全体がハ
ングアップすることなく、以降のシステムの処理をでき
るだけ継続することを可能にしたシステム自動再立ち上
げ制御方式に関する。

【０００２】

【従来の技術】従来の技術として、「特開昭５６−４８
４８号公報」のように装置外部にチェック手段、およ
び、カウンタを設けることにより当該装置の再起動を実
現していた。また、「特開昭５６−１２７２５６号公
報」のようにアプリケーション実行時の障害を検知する
技術や「特開平５−２３３３４１号公報」においては、
アプリケーション障害検知後の再起動を無限に繰り返さ
ない公知技術はあるが、一装置内でのアプリケーション
障害検知に対して、そのアプリケーションの再起動要／
否のプライオリティレベルでの自動判定により、再起動
する一連の流れの方式については、考慮されていなかっ
た。

【０００３】

【発明が解決しようとする課題】前記従来の技術は、外
部装置により業務アプリケーションエラー検知を行って
おり、また、業務アプリケーションの重要性について配
慮されておらず、業務アプリケーションエラーを検知
後、無条件に再起動を行っていた。本発明は、装置内で
プログラムのエラー検知を行い、プログラムエラー検知
時に、自動的にエラーの発生したプログラムのレベルに
応じてプログラムの再起動またはプログラムの終了を実
行するようにして、装置（システム）全体がハングアッ
プすることなく、以降のシステムの処理をできるだけ継
続することを目的としている。

【０００４】

【課題を解決するための手段】本発明は、上記目的を達
成するために、装置に搭載しているプログラム毎にエラ
ー発生時の再起動レベルをプライオリティ記憶手段（プ
ライオリティテーブル１３）に登録しておく。そして、
プログラム実行時にエラー発生検知手段（アプリケーシ
ョンエラー検知プロセス１０）によりエラーの発生を検
知すると、プライオリティ記憶手段を参照してエラーの
発生が検知されたプログラムに対する再起動レベルを判
別し、その再起動レベルに基づいてシステムを再起動す
る。再起動レベルとしては、オペレーティングシステム
（ＯＳ）を含めて再起動するか、自身のプログラムだけ
を再起動するか、または自身のプログラムを終了するか
などを規定するレベルなどが考えられる。この構成を採
用することにより、プログラムの重要性に応じた再起動
レベルを設定しておき、その内容に応じて最適なシステ
ムの自動再立ち上げやプログラムの終了を行うことがで
き、結果的に、システムに不必要なハングアップを生じ
させることなく以降の処理を継続させることが可能にな
る。

【０００５】

【発明の実施の形態】以下、本発明の実施例を説明す
る。なお、本発明は、全てのプログラム（ソフトウェ
ア）に適用できるが、以下の説明では、プログラムとし
て業務アプリケーションを中心にして説明する。 （第１の実施例）まず、本発明の第１の実施例を、図１
〜図７を用いて説明する。本実施例は、本発明を現金自
動取引装置の各種業務アプリケーションに適用したもの
で、図１は本実施例のシステム構成図、図２は本実施例
のソフトウェア構成図、図３はプライオリティテーブル
の構造例、図４はアプリケーションエラー管理テーブル
の構造例、図５〜図７は本実施例に係るシステム自動再
立ち上げ制御の流れを説明するための図である。

【０００６】図１は、一般的な銀行内システムの構成を
示している。同図において、１はセンタ側構成である勘
定系ホスト、２はＩＳＤＮ（Ｉntegrated Ｓervices Ｄ
igital Ｎetwork）、３はルータ、４は営業店側構成で
ある営業店サーバ（中継サーバ）、５は営業店端末、６
Ａ〜６Ｂは現金自動取引装置である。

【０００７】勘定系ホストシステム（１）は、営業店端
末（５）や現金自動取引装置（６Ａ〜６Ｂ）でエンドユ
ーザによって行われる各種取引の勘定処理、営業店端末
（５）や現金自動取引装置（６Ａ〜６Ｂ）に対しての出
金または印字などの指示を行うためのホストシステムで
ある。営業店サーバ（４）は、各営業店端末（５）や現
金自動取引装置（６Ａ〜６Ｂ）がそれぞれ勝手にホスト
システム（１）に対して電文送信を行った場合、ホスト
システム（１）側での管理／処理が困難になるため、営
業店内の各装置を統括し、ルータ（３）を介してホスト
システムに情報を送受信するための中継サーバである。
これにより、ホストシステム（１）は、通信する装置と
して営業店サーバ（４）単位で管理することとなる。

【０００８】図２は、本実施例における現金自動取引装
置（６Ａ〜６Ｂ）のソフトウェア構成例を示す図であ
る。ソフトウェア構成としては、装置を動作させるため
の基本ソフトであるオペレーティングシステム（１５）
と、アプリケーションエラー検知および再起動要否を判
定するためのアプリケーションエラー検知プロセス（１
０）および再起動要否判定プロセス（１１）を含むミド
ルソフトウェア群（９）と、現金自動取引装置（６Ａ〜
６Ｂ）で行われる各種取引を処理する業務アプリケーシ
ョン群（８Ａ〜８Ｂ）と、その他の流通ソフトウェア群
（７Ａ〜７Ｂ）と、再起動判定に必要であるプライオリ
ティテーブル（１３）と、アプリケーションエラー検知
時にエラー内容を登録しておくロギングファイル（１
２）と、アプリケーションエラーが発生した際のエラー
回数や再起動回数を保持しておくためのアプリケーショ
ンエラー管理テーブル（１４）とから構成される。

【０００９】図３は、プライオリティテーブル（１３）
の構造例を示す図である。同図に示すように、プライオ
リティテーブル（１３）は、監視対象となるアプリケー
ション名称を登録する「アプリケーション名称」（１
６）と、アプリケーションエラー検知およびハングアッ
プ検知対象となる主プロセス名称を登録する「プロセス
名称」（１７）と、再起動を行う際の実施レベル（ＯＳ
を含めて再起動を行うまたは自身の業務アプリケーショ
ンのみを再起動するなどのレベル）を登録する「再起動
レベル」（１８）と、再起動を行う際、永久ループに陥
ることを防止するために登録する「再起動回数」（１
９）とから構成される。

【００１０】また、本プライオリティテーブル（１３）
の最初の欄「Ｎｏ．０」（２０）の設定内容は、全アプ
リケーションを対象としたエリアとして位置付ける。全
アプリケーション対象エリアの再起動レベル（２１）の
設定値は「０」（各業務アプリケーションの設定値を有
効にする）と「１」（アプリケーションエラーを検知し
たら無条件にＯＳを含めて再起動する）の２通りの設定
方法を設ける。図３の場合は再起動レベルが「０」、再
起動回数が「３」の場合を示している。

【００１１】また、各業務アプリケーション対象エリア
の再起動レベル（２２）の設定値として「Ａ」「Ｂ」
「Ｃ」の３通りの設定方法を設ける。ここで、「Ａ」は
“ＯＳを含めて再起動する”を意味し、「Ｂ」は“自身
の業務アプリケーションのみを終了する”を意味し、
「Ｃ」は、“自身の業務アプリケーションのみを再起動
する”を意味する。

【００１２】図４は、アプリケーションエラー管理テー
ブル（１４）の構造例を示す図である。同図に示すよう
に、アプリケーションエラー管理テーブル（１４）は、
監視対象となるアプリケーション名称を登録する「アプ
リケーション名称」（１６）（本名称はプライオリティ
テーブル（１３）に登録することで自動的に反映され
る）と、アプリケーションエラーの発生した回数を管理
する「エラー発生回数」（２４）と、再起動を行った回
数を保持する「再起動実施回数」（２５）とから構成さ
れる。

【００１３】全業務アプリケーション対象および各業務
アプリケーション対象の再起動レベルが再起動実施要の
設定がされている場合は、再起動処理を行う都度、図４
のアプリケーションエラー管理テーブル（１４）の再起
動実施回数（２５）を＋１づつ更新する。「再起動回
数」（１９）に設定されている回数分再起動処理を行っ
た後に再度アプリケーションエラーを検知した場合は、
保守員によるエラー要因除去などが必要な旨のメッセー
ジを表示するとともに監視システムに対しても通知を行
う。

【００１４】図５は、自身の業務アプリケーションのみ
を終了する場合のシステム自動再立ち上げの例を示す図
である。はじめに各プロセスの機能分担を説明する。同
図において、業務アプリケーション２（２６）は現金自
動取引装置（６Ａ〜６Ｂ）で動作するアプリケーション
でプライオリティテーブル（１３）の再起動レベルが
「Ｂ」を有しており、該アプリケーションのみを終了し
ても現金自動取引装置（６Ａ〜６Ｂ）全体としての機能
に特に弊害を与えないアプリケーションである（例え
ば、現金自動取引装置において、入金取引を処理するア
プリケーションを終了しても、出金その他の取引に影響
はない）。

【００１５】システム管理プロセス（２７）は、再起動
要否判定プロセス（２９）から通知された処理内容やエ
ラー内容をロギングファイル（１２）に取得し、各アプ
リケーションへの終了指示、システムの再起動などの処
理を行う。アプリケーションエラー検知プロセス（２
８）は、プライオリティテーブル（１３）に登録されて
いるアプリケーションの状態を監視するプロセスであ
る。再起動要否判定プロセス（２９）は、アプリケーシ
ョンエラー検知プロセス（２８）から通知される「アプ
リケーションエラー発生通知」により再起動を行うか否
かをプライオリティテーブル（１３）を参照して判定
し、判定した結果をシステム管理プロセス（２７）に通
知するプロセスである。

【００１６】本例において、プライオリティテーブル
（１３）の再起動レベル（１８）が「Ｂ（自身の業務ア
プリケーションのみを終了する）」と設定されている業
務アプリケーション２（２６）でアプリケーションエラ
ーが発生し（ステップ３０）、そのエラーをアプリケー
ションエラー検知プロセス（２８）が検知する（ステッ
プ３１）。アプリケーションエラー検知プロセス（２
８）は、エラーの発生したアプリケーション名称などを
再起動要否判定プロセス（２９）に通知する（ステップ
３２）。エラー通知を受信した再起動要否判定プロセス
（２９）は、プライオリティテーブル（１３）をサーチ
し、処理を判定する（ステップ３３）。再起動要否判定
プロセス（２９）は、判定した結果をシステム管理プロ
セス（２７）に「アプリケーション終了指示」として通
知する（ステップ３４）。

【００１７】指示を受信したシステム管理プロセス（２
７）は、アプリケーションエラーの発生した業務アプリ
ケーション名称、エラー発生内容などをロギングデータ
取得処理（ステップ３５）にてロギングファイル（１
２）に取得後（ステップ３６）、アプリケーションの終
了処理を行う（ステップ３７，ステップ３８）。その結
果、エラーの発生した業務アプリケーションのみを終了
し（ステップ３９）、一連の流れを完了する。

【００１８】図６は、自身の業務アプリケーションのみ
を再起動する場合のシステム自動再立ち上げの例を示す
図である。本例において、流通ソフトウェア２（４０）
は、インターネットなどを通じて各種情報を現金自動取
引装置（６Ａ〜６Ｂ）に表示するためのアプリケーショ
ンでプライオリティテーブル（１３）の再起動レベルが
「Ｃ」を有しており、例えば当該サービスだけを運用し
ている時間帯（深夜など）にエラーが発生した場合は、
現金自動取引装置（６Ａ〜６Ｂ）として何もサービスの
提供ができなくなるため当該アプリケーションを再起動
し、サービスを提供できる状態にする。その他の各プロ
セスの機能分担については、図５で説明した内容と同じ
である。

【００１９】本例では、プライオリティテーブル（１
３）の再起動レベルが「Ｃ（自身の業務アプリケーショ
ンのみを再起動する）」と設定されている流通ソフトウ
ェア２（４０）でアプリケーションエラーが発生し（ス
テップ３０）、その発生したエラーをアプリケーション
エラー検知プロセス（２８）が検知する（ステップ３
１）。尚、業務アプリケーション２（２６）は、正常に
動作している状態である。

【００２０】アプリケーションエラー検知プロセス（２
８）は、エラーの発生したアプリケーション名称などを
再起動要否判定プロセス（２９）に通知する（ステップ
３２）。エラー通知を受信した再起動要否判定プロセス
（２９）は、プライオリティテーブル（１３）をサーチ
し、処理を判定する（ステップ３３）。本例では、再起
動レベルが「Ｃ」すなわち自身のアプリケーションのみ
を再起動すると設定されているため、まず、アプリケー
ションエラー管理テーブル（１４）の再起動実施回数
（２５）を＋１更新処理（ステップ４１）して再格納す
る（ステップ４２）。

【００２１】次に、プライオリティテーブル（１３）に
設定されている再起動回数（１９）とアプリケーション
エラー管理テーブル（１４）の再起動実施回数（２５）
を比較し（ステップ４３）、再起動実施回数（２５）が
再起動回数（１９）以下の場合、システム管理プロセス
（２７）に対してアプリケーション再起動指示を通知す
る（ステップ４４）。指示を受信したシステム管理プロ
セス（２７）は、アプリケーションエラーの発生した業
務アプリケーション名称、エラー発生内容などをロギン
グデータ取得処理（ステップ３５）にてロギングファイ
ル（１２）に取得後（ステップ３６）、アプリケーショ
ンの終了処理（ステップ３７，ステップ３８）を行った
後、アプリケーションの再起動処理（ステップ４５）に
てアプリケーションを再起動する。その結果、業務アプ
リケーションが再起動され（ステップ４７）、一連の流
れを完了する。

【００２２】また、プライオリティテーブル（１３）に
設定されている再起動回数（１９）とアプリケーション
エラー管理テーブル（１４）の再起動実施回数（２５）
を比較した結果（ステップ４３）、再起動実施回数（２
５）の方が再起動回数（１９）より多い場合は、システ
ム管理プロセス（２７）に対してアプリケーション終了
指示を通知する（ステップ３４）。指示を受信したシス
テム管理プロセス（２７）は、アプリケーションエラー
の発生した業務アプリケーション名称、エラー発生内容
などをロギングデータ取得処理（ステップ３５）にてロ
ギングファイル（１２）に取得した後（ステップ３
６）、アプリケーションの終了処理を行う（ステップ３
７，ステップ３８）。その結果、エラーの発生した業務
アプリケーションのみを終了する（ステップ３９）。

【００２３】尚、アプリケーションエラー管理テーブル
（１４）の再起動実施回数（２５）については、保守員
などによるオペレーションにより“０クリア”を可能と
する。また、前記のように再起動実施回数を超えるよう
な場合は、保守員などによるエラー要因除去などの作業
が必要な旨のメッセージを表示する。

【００２４】図７は、ＯＳを含めて再起動する場合のシ
ステム自動再立ち上げの例を示す図である。業務アプリ
ケーション１（４８）は、業務アプリケーション群とミ
ドルソフトウェア郡とを連携するための重要なアプリケ
ーションでプライオリティテーブル（１３）の再起動レ
ベルが「Ａ」を有しており、当該アプリケーションにエ
ラーが発生した場合、現金自動取引装置（６Ａ〜６Ｂ）
としての動作が不安定となり、各種取引に影響が出る恐
れがある。その他の各プロセスの機能分担については、
図５で説明した内容と同じである。

【００２５】本例では、プライオリティテーブル（１
３）で「Ａ（ＯＳを含めて再起動する）」と設定されて
いる業務アプリケーション１（４８）でアプリケーショ
ンエラーが発生し（ステップ３０）、そのエラーをアプ
リケーションエラー検知プロセス（２８）が検知する
（ステップ３１）。尚、業務アプリケーション２（２
６）は、正常に動作している状態である。エラーの発生
したアプリケーション名称などを再起動要否判定プロセ
ス（２９）に通知する（ステップ３２）。エラー通知を
受信した再起動要否判定プロセス２９は、プライオリテ
ィテーブル（１３）をサーチし、処理を判定する（ステ
ップ３３）。本例では、プライオリティテーブル（１
３）の再起動レベル（１８）が「Ａ」でありＯＳを含め
て再起動すると設定されているため、まずアプリケーシ
ョンエラー管理テーブル（１４）の再起動実施回数（２
５）を＋１更新処理（ステップ４１）してアプリケーシ
ョンエラー管理テーブル（１４）への格納を行う（ステ
ップ４２）。

【００２６】次に、プライオリティテーブル（１３）に
設定されている再起動回数（１９）とアプリケーション
エラー管理テーブル（１４）の再起動実施回数（２５）
をし比較（ステップ４３）、再起動実施回数（２５）が
再起動回数以下の場合、システム管理プロセス（２７）
に対してシステム再起動指示を通知する（ステップ４
９）。指示を受信したシステム管理プロセス（２７）
は、アプリケーションエラーの発生した業務アプリケー
ション名称、エラー発生内容などをロギングデータ取得
処理にてロギングファイル（１２）に取得した後（ステ
ップ３６）、自身のシステム終了処理（ステップ５０）
および各アプリケーション終了処理（ステップ３７，ス
テップ３８）にて全業務アプリケーションを終了する
（ステップ３９）。その後、システム自身が再起動され
（ステップ５１）、各業務アプリケーションも開始され
（ステップ５２）、一連の流れを完了する。

【００２７】また、プライオリティテーブル（１３）に
設定されている再起動回数（１９）とアプリケーション
エラー管理テーブル（１４）の再起動実施回数（２５）
を比較した結果（ステップ４３）、再起動実施回数（２
５）の方が再起動回数（１９）より多い場合は、システ
ム管理プロセス（２７）に対してアプリケーション終了
指示を通知する（ステップ３４）。指示を受信したシス
テム管理プロセス（２７）は、アプリケーションエラー
の発生した業務アプリケーション名称、エラー発生内容
などをロギングデータ取得処理にてロギングファイル
（１２）に取得後（ステップ３６）、アプリケーション
の終了処理を行う（ステップ３７，ステップ３８）。そ
の結果、エラーの発生した業務アプリケーションのみを
終了する（ステップ３９）。

【００２８】尚、アプリケーションエラー管理テーブル
（１４）の再起動実施回数（２５）については、保守員
などによるオペレーションにより“０クリア”を可能と
する。また、上記のように再起動実施回数を超えるよう
な場合は、保守員などによるエラー要因除去などの作業
が必要な旨のメッセージを表示する。

【００２９】次に、本発明の第２の実施例について説明
する。本実施例は、本発明をワープロソフトや表計算ソ
フトなどの業務アプリケーションに適用したものであ
る。図８は本実施例のシステム構成図であり、図９は本
発明のソフトウェア構成図であり、図１０はプライオリ
ティテーブルの構造例を表し、図１１はアプリケーショ
ンエラー管理テーブルの構造例を示している。第１の実
施例と同様のものには同一の符号を付与している。

【００３０】図８において、１Ａ〜１Ｂは監視センタ側
構成である監視サーバ、２はＩＳＤＮ、３Ａと３Ｂはル
ータ、６Ａ〜６Ｃは現金自動取引装置、２Ａ〜２Ｂは監
視クライアント、５０は支店監視装置である。

【００３１】監視サーバ（１Ａ〜１Ｂ）および監視クラ
イアント（２Ａ〜２Ｂ）は、早朝・夜間および休日等営
業店が無人となる時間帯における現金自動取引装置（６
Ａ〜６Ｃ）の稼働状況を監視するシステムである。支店
監視装置（５０）は、営業店が有人となる時間帯におい
て営業店行員で現金自動取引装置（６Ａ〜６Ｃ）の稼働
状況を監視するための装置であり、また、営業店が無人
となる時間帯においては、現金自動取引装置（６Ａ〜６
Ｃ）の障害情報をルータ（３Ａ〜３Ｂ）を介してセンタ
側システムに情報を送信する機能を有する。

【００３２】図９は、支店監視装置（５０）のソフトウ
ェア構成図であり、装置を動作させるためのオペレーテ
ィングシステム（１５）と、アプリケーションエラー検
知のためのアプリケーションエラー検知プロセス（１
０）と、再起動要否を判定するための再起動要否判定プ
ロセス（１１）と、現金自動取引装置の稼働状況を監視
する業務アプリケーション（８Ａ）と、その他の業務ア
プリケーション群（８Ｂ〜８ｎ）と、再起動判定に必要
であるプライオリティテーブル（１３）と、アプリケー
ションエラー検知時にエラー内容を登録しておくロギン
グファイル（１２）と、アプリケーションエラーが発生
した際のエラー回数および再起動回数を保持しておくた
めのアプリケーションエラー管理テーブル（１４）とか
ら構成される。

【００３３】図１０は、本実施例におけるプライオリテ
ィテーブル（１３）の構造例を示す図である。本実施例
におけるプライオリティテーブル（１３）は、同図に示
すように、監視対象となる業務アプリケーション名称
（１６）と、アプリケーションエラー検知およびハング
アップ検知対象となる主プロセス名称（１７）と、再起
動を行う際の再起動レベル（１８）（ＯＳを含めて再起
動を行うのか自身の業務アプリケーションのみを再起動
するのかなどを指定する再起動レベル）と、再起動を行
う際、永久ループに陥ることを防止するために登録する
再起動回数（１９）から構成される。また、最初の項目
である「Ｎｏ．０」（２０）については、全業務アプリ
ケーションを対象として設定するエリアとして位置付け
る。

【００３４】プライオリティテーブル（１３）におい
て、全業務アプリケーション対象エリアの再起動レベル
（１８）の設定値は「０」（各業務アプリケーションの
設定値を有効にする）と「１」（アプリケーションエラ
ーを検知したら無条件にＯＳを含めて再起動する）の２
通りの設定方法を設ける。また、各業務アプリケーショ
ン対象エリアの再起動レベル（１８）の設定値は、
「Ａ」（ＯＳを含めて再起動する）、「Ｂ」（自身の業
務アプリケーションのみを終了する）、「Ｃ」（自身の
業務アプリケーションのみを再起動する）の３通りの設
定方法を設ける。

【００３５】図１０の例では、業務アプリケーション名
称が「監視機能」の再起動レベル（１８）が「Ａ」、オ
ペレータにより操作され報告書などを作成するためのア
プリケーション「ワープロ」の再起動レベル（１８）が
「Ｂ」、オペレータにより操作され見積書などを作成す
るためのアプリケーション「表計算」の再起動レベル
（１８）が「Ｃ」に設定されている。

【００３６】図１１は、アプリケーションエラー管理テ
ーブル（１４）の構造例を示す図である。アプリケーシ
ョンエラー管理テーブル（１４）は、同図に示すよう
に、監視対象となる業務アプリケーション名称（１６）
と、アプリケーションエラーの発生した回数（２４）と
再起動を行った回数を保持する再起動実施回数（２５）
と含んでいる。

【００３７】尚、プライオリティテーブル（１３）にお
いて、全業務アプリケーション対象エリアの再起動レベ
ルが「１」で、各業務アプリケーション対象エリアの再
起動レベルが「Ａ」と設定されている場合（今の例では
「監視機能」）は、再起動処理を行う都度、図１１のア
プリケーションエラー管理テーブル（１４）の再起動実
施回数（２５）を＋１づつ更新する。設定されている回
数分再起動処理を行った後で再度アプリケーションエラ
ーを検知した場合は、保守員によるエラー要因除去等が
必要な旨のメッセージを表示する。

【００３８】図１０および図１１の設定において、業務
アプリケーション（ワープロ）でエラーが発生した場合
には、プライオリティテーブル（１３）の再起動レベル
（１８）が「Ｂ」であるので、図５で説明したのと同様
の流れにより自身の業務アプリケーション（ワープロ）
のみを終了する。ただし、図５において「業務アプリケ
ーション２（２６）」を「業務アプリケーション（ワー
プロ）（２６）」に変更した流れになる。

【００３９】また、業務アプリケーション（表計算）で
エラーが発生した場合には、プライオリティテーブル
（１３）の再起動レベル（１８）が「Ｃ」であるので、
図６で説明したのと同様の流れにより自身の業務アプリ
ケーション（表計算）のみを再起動する。この場合、例
えば、図６において「業務アプリケーション２（２
６）」を「業務アプリケーション（ワープロ）（２
６）」に、「流通ソフトウェア２（４０）」を「業務ア
プリケーション（表計算）（４０）」に変更した流れに
なる。

【００４０】さらに、監視機能でエラーが発生した場合
には、プライオリティテーブル（１３）の再起動レベル
（１８）が「Ａ」であるので、図７で説明したのと同様
の流れによりＯＳを含めて再起動する。この場合、例え
ば、図６において「業務アプリケーション２（２６）」
を「業務アプリケーション（ワープロ）（２６）」に、
「業務アプリケーション１（４８）」を「業務アプリケ
ーション（監視機能）（４８）」に変更した流れにな
る。

【００４１】以上述べたように、本実施例によれば、業
務アプリケーションごとに再起動レベルを設定しておく
ことにより、ある業務アプリケーションにエラーが発生
した場合に、エラーを発生した当該業務アプリケーショ
ンの設定されている再起動レベルに応じて、自動的に再
起動，終了など行うようにし、システム全体をハングア
ップさせることなく業務を継続することができる。

【００４２】

【発明の効果】本発明によれば、無人運用を行っている
装置で業務アプリケーションエラーが発生した場合でも
装置自身で再立ち上げまたは当該業務アプリケーション
のみの終了を判定し、処理することでエラー発生後もハ
ングアップすることなく継続して業務を行うことが可能
になり、従来、無人運用を行っている装置で業務アプリ
ケーションエラーが発生した場合、エラーが発生した時
点でシステムがハングアップしてしまい、以降の業務を
継続することができなかったという問題を解消できる。

【図面の簡単な説明】

【図１】本発明を適用する第１の実施例のシステム構成
図である。

【図２】本発明の第１の実施例に係るソフトウェア構成
図である。

【図３】本発明の第１の実施例に係るプライオリティテ
ーブルの構造図である。

【図４】本発明の第１の実施例に係るアプリケーション
エラー管理テーブルの構造図である。

【図５】本発明の第１の実施例に係るシステム自動再立
ち上げの流れを説明するための図である（自身の業務ア
プリケーションのみを終了する場合）。

【図６】本発明の第１の実施例に係るシステム自動再立
ち上げの流れを説明するための図である（自身の業務ア
プリケーションのみを再起動する場合）。

【図７】本発明の第１の実施例に係るシステム自動再立
ち上げの流れを説明するための図である（ＯＳを含めて
再起動する場合）。

【図８】本発明を適用する第２の実施例のシステム構成
図である。

【図９】本発明の第２の実施例に係るソフトウェア構成
図である。

【図１０】本発明の第２の実施例に係るプライオリティ
テーブルの構造図である。

【図１１】本発明の第２の実施例に係るアプリケーショ
ンエラー管理テーブルの構造図である。

【符号の説明】

１…勘定系ホスト（ホストシステム）、 １Ａ〜１Ｂ…監視サーバ、 ２…ＩＳＤＮ、 ２Ａ〜２Ｂ…監視クライアント、 ３，３Ａ，３Ｂ…ルータ、 ４…営業店サーバ、 ５…営業店端末、 ６Ａ〜６Ｃ…現金自動取引装置、 ７Ａ〜７Ｂ…流通ソフトウェア、 ８Ａ〜８ｎ…業務アプリケーション、 ９…ミドルソフトウェア群、 １０…アプリケーションエラー検知プロセス、 １１…再起動要否判定プロセス、 １２…ロギングファイル、 １３…プライオリティテーブル、 １４…アプリケーションエラー管理テーブル、 １５…オペレーティングシステム（ＯＳ）、 ５０…支店監視装置。

Claims (3)

【特許請求の範囲】
1. 【請求項１】 複数のプログラムを搭載した装置におけ
   るシステム自動再立ち上げ制御方式において、 各プログラム毎にエラー発生時の再起動レベルを登録し
   たプライオリティ記憶手段と、プログラム実行時におけ
   るエラーの発生を検知するエラー発生検知手段と、前記
   プライオリティ記憶手段を参照し、前記エラー発生検知
   手段によりエラーの発生が検知されたプログラムに対す
   る再起動レベルを判別する手段を有し、該判別された再
   起動レベルに基づいてシステムを再起動することを特徴
   とするシステム自動再立ち上げ制御方式。
2. 【請求項２】 前記再起動レベルは、オペレーティング
   システム（ＯＳ）を含めてシステムを再起動するレベ
   ル、自身のプログラムのみを再起動するレベル、自身の
   プログラムのみを終了するレベルからなることを特徴と
   する請求項１記載のシステム自動再立ち上げ制御方式。
3. 【請求項３】 前記プライオリティ記憶手段は、プログ
   ラム毎にさらに所定の再起動回数を記憶し、再起動実施
   回数が該所定の再起動回数を越えた場合に、その旨を外
   部に報知することを特徴とする請求項１または２記載の
   システム自動再立ち上げ制御方式。