JP3711789B2

JP3711789B2 - System automatic restart control method and system automatic restart control system

Info

Publication number: JP3711789B2
Application number: JP16112499A
Authority: JP
Inventors: 章生山田; 明美幸村
Original assignee: Hitachi Omron Terminal Solutions Corp
Current assignee: Hitachi Channel Solutions Corp
Priority date: 1999-06-08
Filing date: 1999-06-08
Publication date: 2005-11-02
Anticipated expiration: 2019-06-08
Also published as: JP2000347759A

Description

【０００１】
【発明の属する技術分野】
本発明は、複数のプログラム（業務アプリケーションなど）を搭載した装置のシステム自動再立ち上げ制御方法およびシステム自動再立ち上げシステムに関し、特に、装置全体がハングアップすることなく、以降のシステムの処理をできるだけ継続することを可能にしたシステム自動再立ち上げ制御方法およびシステム自動再立ち上げ制御システムに関する。
【０００２】
【従来の技術】
従来の技術として、「特開昭５６−４８４８号公報」のように装置外部にチェック手段、および、カウンタを設けることにより当該装置の再起動を実現していた。また、「特開昭５６−１２７２５６号公報」のようにアプリケーション実行時の障害を検知する技術や「特開平５−２３３３４１号公報」においては、アプリケーション障害検知後の再起動を無限に繰り返さない公知技術はあるが、一装置内でのアプリケーション障害検知に対して、そのアプリケーションの再起動要／否のプライオリティレベルでの自動判定により、再起動する一連の流れの方式については、考慮されていなかった。
【０００３】
【発明が解決しようとする課題】
前記従来の技術は、外部装置により業務アプリケーションエラー検知を行っており、また、業務アプリケーションの重要性について配慮されておらず、業務アプリケーションエラーを検知後、無条件に再起動を行っていた。
本発明は、装置内でプログラムのエラー検知を行い、プログラムエラー検知時に、自動的にエラーの発生したプログラムのレベルに応じてプログラムの再起動またはプログラムの終了を実行するようにして、装置（システム）全体がハングアップすることなく、以降のシステムの処理をできるだけ継続することを目的としている。
【０００４】
【課題を解決するための手段】
本発明は、上記目的を達成するために、装置に搭載しているプログラム毎にエラー発生時の再起動レベルをプライオリティ記憶手段（プライオリティテーブル１３）に登録しておく。そして、プログラム実行時にエラー発生検知手段（アプリケーションエラー検知プロセス１０）によりエラーの発生を検知すると、プライオリティ記憶手段を参照してエラーの発生が検知されたプログラムに対する再起動レベルを判別し、その再起動レベルに基づいてシステムを再起動する。再起動レベルとしては、オペレーティングシステム（ＯＳ）を含めて再起動するか、自身のプログラムだけを再起動するか、または自身のプログラムを終了するかなどを規定するレベルなどが考えられる。
この構成を採用することにより、プログラムの重要性に応じた再起動レベルを設定しておき、その内容に応じて最適なシステムの自動再立ち上げやプログラムの終了を行うことができ、結果的に、システムに不必要なハングアップを生じさせることなく以降の処理を継続させることが可能になる。
【０００５】
【発明の実施の形態】
以下、本発明の実施例を説明する。なお、本発明は、全てのプログラム（ソフトウェア）に適用できるが、以下の説明では、プログラムとして業務アプリケーションを中心にして説明する。
（第１の実施例）
まず、本発明の第１の実施例を、図１〜図７を用いて説明する。
本実施例は、本発明を現金自動取引装置の各種業務アプリケーションに適用したもので、図１は本実施例のシステム構成図、図２は本実施例のソフトウェア構成図、図３はプライオリティテーブルの構造例、図４はアプリケーションエラー管理テーブルの構造例、図５〜図７は本実施例に係るシステム自動再立ち上げ制御の流れを説明するための図である。
【０００６】
図１は、一般的な銀行内システムの構成を示している。
同図において、１はセンタ側構成である勘定系ホスト、２はＩＳＤＮ（Ｉntegrated Ｓervices Ｄigital Ｎetwork）、３はルータ、４は営業店側構成である営業店サーバ（中継サーバ）、５は営業店端末、６Ａ〜６Ｂは現金自動取引装置である。
【０００７】
勘定系ホストシステム（１）は、営業店端末（５）や現金自動取引装置（６Ａ〜６Ｂ）でエンドユーザによって行われる各種取引の勘定処理、営業店端末（５）や現金自動取引装置（６Ａ〜６Ｂ）に対しての出金または印字などの指示を行うためのホストシステムである。営業店サーバ（４）は、各営業店端末（５）や現金自動取引装置（６Ａ〜６Ｂ）がそれぞれ勝手にホストシステム（１）に対して電文送信を行った場合、ホストシステム（１）側での管理／処理が困難になるため、営業店内の各装置を統括し、ルータ（３）を介してホストシステムに情報を送受信するための中継サーバである。これにより、ホストシステム（１）は、通信する装置として営業店サーバ（４）単位で管理することとなる。
【０００８】
図２は、本実施例における現金自動取引装置（６Ａ〜６Ｂ）のソフトウェア構成例を示す図である。
ソフトウェア構成としては、装置を動作させるための基本ソフトであるオペレーティングシステム（１５）と、アプリケーションエラー検知および再起動要否を判定するためのアプリケーションエラー検知プロセス（１０）および再起動要否判定プロセス（１１）を含むミドルソフトウェア群（９）と、現金自動取引装置（６Ａ〜６Ｂ）で行われる各種取引を処理する業務アプリケーション群（８Ａ〜８Ｂ）と、その他の流通ソフトウェア群（７Ａ〜７Ｂ）と、再起動判定に必要であるプライオリティテーブル（１３）と、アプリケーションエラー検知時にエラー内容を登録しておくロギングファイル（１２）と、アプリケーションエラーが発生した際のエラー回数や再起動回数を保持しておくためのアプリケーションエラー管理テーブル（１４）とから構成される。
【０００９】
図３は、プライオリティテーブル（１３）の構造例を示す図である。
同図に示すように、プライオリティテーブル（１３）は、監視対象となるアプリケーション名称を登録する「アプリケーション名称」（１６）と、アプリケーションエラー検知およびハングアップ検知対象となる主プロセス名称を登録する「プロセス名称」（１７）と、再起動を行う際の実施レベル（ＯＳを含めて再起動を行うまたは自身の業務アプリケーションのみを再起動するなどのレベル）を登録する「再起動レベル」（１８）と、再起動を行う際、永久ループに陥ることを防止するために登録する「再起動回数」（１９）とから構成される。
【００１０】
また、本プライオリティテーブル（１３）の最初の欄「Ｎｏ．０」（２０）の設定内容は、全アプリケーションを対象としたエリアとして位置付ける。全アプリケーション対象エリアの再起動レベル（２１）の設定値は「０」（各業務アプリケーションの設定値を有効にする）と「１」（アプリケーションエラーを検知したら無条件にＯＳを含めて再起動する）の２通りの設定方法を設ける。図３の場合は再起動レベルが「０」、再起動回数が「３」の場合を示している。
【００１１】
また、各業務アプリケーション対象エリアの再起動レベル（２２）の設定値として「Ａ」「Ｂ」「Ｃ」の３通りの設定方法を設ける。ここで、「Ａ」は“ＯＳを含めて再起動する”を意味し、「Ｂ」は“自身の業務アプリケーションのみを終了する”を意味し、「Ｃ」は、“自身の業務アプリケーションのみを再起動する”を意味する。
【００１２】
図４は、アプリケーションエラー管理テーブル（１４）の構造例を示す図である。
同図に示すように、アプリケーションエラー管理テーブル（１４）は、監視対象となるアプリケーション名称を登録する「アプリケーション名称」（１６）（本名称はプライオリティテーブル（１３）に登録することで自動的に反映される）と、アプリケーションエラーの発生した回数を管理する「エラー発生回数」（２４）と、再起動を行った回数を保持する「再起動実施回数」（２５）とから構成される。
【００１３】
全業務アプリケーション対象および各業務アプリケーション対象の再起動レベルが再起動実施要の設定がされている場合は、再起動処理を行う都度、図４のアプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）を＋１づつ更新する。「再起動回数」（１９）に設定されている回数分再起動処理を行った後に再度アプリケーションエラーを検知した場合は、保守員によるエラー要因除去などが必要な旨のメッセージを表示するとともに監視システムに対しても通知を行う。
【００１４】
図５は、自身の業務アプリケーションのみを終了する場合のシステム自動再立ち上げの例を示す図である。はじめに各プロセスの機能分担を説明する。
同図において、業務アプリケーション２（２６）は現金自動取引装置（６Ａ〜６Ｂ）で動作するアプリケーションでプライオリティテーブル（１３）の再起動レベルが「Ｂ」を有しており、該アプリケーションのみを終了しても現金自動取引装置（６Ａ〜６Ｂ）全体としての機能に特に弊害を与えないアプリケーションである（例えば、現金自動取引装置において、入金取引を処理するアプリケーションを終了しても、出金その他の取引に影響はない）。
【００１５】
システム管理プロセス（２７）は、再起動要否判定プロセス（２９）から通知された処理内容やエラー内容をロギングファイル（１２）に取得し、各アプリケーションへの終了指示、システムの再起動などの処理を行う。アプリケーションエラー検知プロセス（２８）は、プライオリティテーブル（１３）に登録されているアプリケーションの状態を監視するプロセスである。再起動要否判定プロセス（２９）は、アプリケーションエラー検知プロセス（２８）から通知される「アプリケーションエラー発生通知」により再起動を行うか否かをプライオリティテーブル（１３）を参照して判定し、判定した結果をシステム管理プロセス（２７）に通知するプロセスである。
【００１６】
本例において、プライオリティテーブル（１３）の再起動レベル（１８）が「Ｂ（自身の業務アプリケーションのみを終了する）」と設定されている業務アプリケーション２（２６）でアプリケーションエラーが発生し（ステップ３０）、そのエラーをアプリケーションエラー検知プロセス（２８）が検知する（ステップ３１）。アプリケーションエラー検知プロセス（２８）は、エラーの発生したアプリケーション名称などを再起動要否判定プロセス（２９）に通知する（ステップ３２）。エラー通知を受信した再起動要否判定プロセス（２９）は、プライオリティテーブル（１３）をサーチし、処理を判定する（ステップ３３）。再起動要否判定プロセス（２９）は、判定した結果をシステム管理プロセス（２７）に「アプリケーション終了指示」として通知する（ステップ３４）。
【００１７】
指示を受信したシステム管理プロセス（２７）は、アプリケーションエラーの発生した業務アプリケーション名称、エラー発生内容などをロギングデータ取得処理（ステップ３５）にてロギングファイル（１２）に取得後（ステップ３６）、アプリケーションの終了処理を行う（ステップ３７，ステップ３８）。その結果、エラーの発生した業務アプリケーションのみを終了し（ステップ３９）、一連の流れを完了する。
【００１８】
図６は、自身の業務アプリケーションのみを再起動する場合のシステム自動再立ち上げの例を示す図である。
本例において、流通ソフトウェア２（４０）は、インターネットなどを通じて各種情報を現金自動取引装置（６Ａ〜６Ｂ）に表示するためのアプリケーションでプライオリティテーブル（１３）の再起動レベルが「Ｃ」を有しており、例えば当該サービスだけを運用している時間帯（深夜など）にエラーが発生した場合は、現金自動取引装置（６Ａ〜６Ｂ）として何もサービスの提供ができなくなるため当該アプリケーションを再起動し、サービスを提供できる状態にする。その他の各プロセスの機能分担については、図５で説明した内容と同じである。
【００１９】
本例では、プライオリティテーブル（１３）の再起動レベルが「Ｃ（自身の業務アプリケーションのみを再起動する）」と設定されている流通ソフトウェア２（４０）でアプリケーションエラーが発生し（ステップ３０）、その発生したエラーをアプリケーションエラー検知プロセス（２８）が検知する（ステップ３１）。尚、業務アプリケーション２（２６）は、正常に動作している状態である。
【００２０】
アプリケーションエラー検知プロセス（２８）は、エラーの発生したアプリケーション名称などを再起動要否判定プロセス（２９）に通知する（ステップ３２）。エラー通知を受信した再起動要否判定プロセス（２９）は、プライオリティテーブル（１３）をサーチし、処理を判定する（ステップ３３）。本例では、再起動レベルが「Ｃ」すなわち自身のアプリケーションのみを再起動すると設定されているため、まず、アプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）を＋１更新処理（ステップ４１）して再格納する（ステップ４２）。
【００２１】
次に、プライオリティテーブル（１３）に設定されている再起動回数（１９）とアプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）を比較し（ステップ４３）、再起動実施回数（２５）が再起動回数（１９）以下の場合、システム管理プロセス（２７）に対してアプリケーション再起動指示を通知する（ステップ４４）。指示を受信したシステム管理プロセス（２７）は、アプリケーションエラーの発生した業務アプリケーション名称、エラー発生内容などをロギングデータ取得処理（ステップ３５）にてロギングファイル（１２）に取得後（ステップ３６）、アプリケーションの終了処理（ステップ３７，ステップ３８）を行った後、アプリケーションの再起動処理（ステップ４５）にてアプリケーションを再起動する。その結果、業務アプリケーションが再起動され（ステップ４７）、一連の流れを完了する。
【００２２】
また、プライオリティテーブル（１３）に設定されている再起動回数（１９）とアプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）を比較した結果（ステップ４３）、再起動実施回数（２５）の方が再起動回数（１９）より多い場合は、システム管理プロセス（２７）に対してアプリケーション終了指示を通知する（ステップ３４）。指示を受信したシステム管理プロセス（２７）は、アプリケーションエラーの発生した業務アプリケーション名称、エラー発生内容などをロギングデータ取得処理（ステップ３５）にてロギングファイル（１２）に取得した後（ステップ３６）、アプリケーションの終了処理を行う（ステップ３７，ステップ３８）。その結果、エラーの発生した業務アプリケーションのみを終了する（ステップ３９）。
【００２３】
尚、アプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）については、保守員などによるオペレーションにより“０クリア”を可能とする。また、前記のように再起動実施回数を超えるような場合は、保守員などによるエラー要因除去などの作業が必要な旨のメッセージを表示する。
【００２４】
図７は、ＯＳを含めて再起動する場合のシステム自動再立ち上げの例を示す図である。
業務アプリケーション１（４８）は、業務アプリケーション群とミドルソフトウェア郡とを連携するための重要なアプリケーションでプライオリティテーブル（１３）の再起動レベルが「Ａ」を有しており、当該アプリケーションにエラーが発生した場合、現金自動取引装置（６Ａ〜６Ｂ）としての動作が不安定となり、各種取引に影響が出る恐れがある。その他の各プロセスの機能分担については、図５で説明した内容と同じである。
【００２５】
本例では、プライオリティテーブル（１３）で「Ａ（ＯＳを含めて再起動する）」と設定されている業務アプリケーション１（４８）でアプリケーションエラーが発生し（ステップ３０）、そのエラーをアプリケーションエラー検知プロセス（２８）が検知する（ステップ３１）。尚、業務アプリケーション２（２６）は、正常に動作している状態である。エラーの発生したアプリケーション名称などを再起動要否判定プロセス（２９）に通知する（ステップ３２）。エラー通知を受信した再起動要否判定プロセス２９は、プライオリティテーブル（１３）をサーチし、処理を判定する（ステップ３３）。本例では、プライオリティテーブル（１３）の再起動レベル（１８）が「Ａ」でありＯＳを含めて再起動すると設定されているため、まずアプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）を＋１更新処理（ステップ４１）してアプリケーションエラー管理テーブル（１４）への格納を行う（ステップ４２）。
【００２６】
次に、プライオリティテーブル（１３）に設定されている再起動回数（１９）とアプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）をし比較（ステップ４３）、再起動実施回数（２５）が再起動回数以下の場合、システム管理プロセス（２７）に対してシステム再起動指示を通知する（ステップ４９）。指示を受信したシステム管理プロセス（２７）は、アプリケーションエラーの発生した業務アプリケーション名称、エラー発生内容などをロギングデータ取得処理にてロギングファイル（１２）に取得した後（ステップ３６）、自身のシステム終了処理（ステップ５０）および各アプリケーション終了処理（ステップ３７，ステップ３８）にて全業務アプリケーションを終了する（ステップ３９）。その後、システム自身が再起動され（ステップ５１）、各業務アプリケーションも開始され（ステップ５２）、一連の流れを完了する。
【００２７】
また、プライオリティテーブル（１３）に設定されている再起動回数（１９）とアプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）を比較した結果（ステップ４３）、再起動実施回数（２５）の方が再起動回数（１９）より多い場合は、システム管理プロセス（２７）に対してアプリケーション終了指示を通知する（ステップ３４）。指示を受信したシステム管理プロセス（２７）は、アプリケーションエラーの発生した業務アプリケーション名称、エラー発生内容などをロギングデータ取得処理にてロギングファイル（１２）に取得後（ステップ３６）、アプリケーションの終了処理を行う（ステップ３７，ステップ３８）。その結果、エラーの発生した業務アプリケーションのみを終了する（ステップ３９）。
【００２８】
尚、アプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）については、保守員などによるオペレーションにより“０クリア”を可能とする。また、上記のように再起動実施回数を超えるような場合は、保守員などによるエラー要因除去などの作業が必要な旨のメッセージを表示する。
【００２９】
次に、本発明の第２の実施例について説明する。本実施例は、本発明をワープロソフトや表計算ソフトなどの業務アプリケーションに適用したものである。
図８は本実施例のシステム構成図であり、図９は本発明のソフトウェア構成図であり、図１０はプライオリティテーブルの構造例を表し、図１１はアプリケーションエラー管理テーブルの構造例を示している。第１の実施例と同様のものには同一の符号を付与している。
【００３０】
図８において、１Ａ〜１Ｂは監視センタ側構成である監視サーバ、２はＩＳＤＮ、３Ａと３Ｂはルータ、６Ａ〜６Ｃは現金自動取引装置、２Ａ〜２Ｂは監視クライアント、５０は支店監視装置である。
【００３１】
監視サーバ（１Ａ〜１Ｂ）および監視クライアント（２Ａ〜２Ｂ）は、早朝・夜間および休日等営業店が無人となる時間帯における現金自動取引装置（６Ａ〜６Ｃ）の稼働状況を監視するシステムである。支店監視装置（５０）は、営業店が有人となる時間帯において営業店行員で現金自動取引装置（６Ａ〜６Ｃ）の稼働状況を監視するための装置であり、また、営業店が無人となる時間帯においては、現金自動取引装置（６Ａ〜６Ｃ）の障害情報をルータ（３Ａ〜３Ｂ）を介してセンタ側システムに情報を送信する機能を有する。
【００３２】
図９は、支店監視装置（５０）のソフトウェア構成図であり、装置を動作させるためのオペレーティングシステム（１５）と、アプリケーションエラー検知のためのアプリケーションエラー検知プロセス（１０）と、再起動要否を判定するための再起動要否判定プロセス（１１）と、現金自動取引装置の稼働状況を監視する業務アプリケーション（８Ａ）と、その他の業務アプリケーション群（８Ｂ〜８ｎ）と、再起動判定に必要であるプライオリティテーブル（１３）と、アプリケーションエラー検知時にエラー内容を登録しておくロギングファイル（１２）と、アプリケーションエラーが発生した際のエラー回数および再起動回数を保持しておくためのアプリケーションエラー管理テーブル（１４）とから構成される。
【００３３】
図１０は、本実施例におけるプライオリティテーブル（１３）の構造例を示す図である。
本実施例におけるプライオリティテーブル（１３）は、同図に示すように、監視対象となる業務アプリケーション名称（１６）と、アプリケーションエラー検知およびハングアップ検知対象となる主プロセス名称（１７）と、再起動を行う際の再起動レベル（１８）（ＯＳを含めて再起動を行うのか自身の業務アプリケーションのみを再起動するのかなどを指定する再起動レベル）と、再起動を行う際、永久ループに陥ることを防止するために登録する再起動回数（１９）から構成される。また、最初の項目である「Ｎｏ．０」（２０）については、全業務アプリケーションを対象として設定するエリアとして位置付ける。
【００３４】
プライオリティテーブル（１３）において、全業務アプリケーション対象エリアの再起動レベル（１８）の設定値は「０」（各業務アプリケーションの設定値を有効にする）と「１」（アプリケーションエラーを検知したら無条件にＯＳを含めて再起動する）の２通りの設定方法を設ける。また、各業務アプリケーション対象エリアの再起動レベル（１８）の設定値は、「Ａ」（ＯＳを含めて再起動する）、「Ｂ」（自身の業務アプリケーションのみを終了する）、「Ｃ」（自身の業務アプリケーションのみを再起動する）の３通りの設定方法を設ける。
【００３５】
図１０の例では、業務アプリケーション名称が「監視機能」の再起動レベル（１８）が「Ａ」、オペレータにより操作され報告書などを作成するためのアプリケーション「ワープロ」の再起動レベル（１８）が「Ｂ」、オペレータにより操作され見積書などを作成するためのアプリケーション「表計算」の再起動レベル（１８）が「Ｃ」に設定されている。
【００３６】
図１１は、アプリケーションエラー管理テーブル（１４）の構造例を示す図である。
アプリケーションエラー管理テーブル（１４）は、同図に示すように、監視対象となる業務アプリケーション名称（１６）と、アプリケーションエラーの発生した回数（２４）と再起動を行った回数を保持する再起動実施回数（２５）と含んでいる。
【００３７】
尚、プライオリティテーブル（１３）において、全業務アプリケーション対象エリアの再起動レベルが「１」で、各業務アプリケーション対象エリアの再起動レベルが「Ａ」と設定されている場合（今の例では「監視機能」）は、再起動処理を行う都度、図１１のアプリケーションエラー管理テーブル（１４）の再起動実施回数（２５）を＋１づつ更新する。設定されている回数分再起動処理を行った後で再度アプリケーションエラーを検知した場合は、保守員によるエラー要因除去等が必要な旨のメッセージを表示する。
【００３８】
図１０および図１１の設定において、業務アプリケーション（ワープロ）でエラーが発生した場合には、プライオリティテーブル（１３）の再起動レベル（１８）が「Ｂ」であるので、図５で説明したのと同様の流れにより自身の業務アプリケーション（ワープロ）のみを終了する。ただし、図５において「業務アプリケーション２（２６）」を「業務アプリケーション（ワープロ）（２６）」に変更した流れになる。
【００３９】
また、業務アプリケーション（表計算）でエラーが発生した場合には、プライオリティテーブル（１３）の再起動レベル（１８）が「Ｃ」であるので、図６で説明したのと同様の流れにより自身の業務アプリケーション（表計算）のみを再起動する。この場合、例えば、図６において「業務アプリケーション２（２６）」を「業務アプリケーション（ワープロ）（２６）」に、「流通ソフトウェア２（４０）」を「業務アプリケーション（表計算）（４０）」に変更した流れになる。
【００４０】
さらに、監視機能でエラーが発生した場合には、プライオリティテーブル（１３）の再起動レベル（１８）が「Ａ」であるので、図７で説明したのと同様の流れによりＯＳを含めて再起動する。この場合、例えば、図６において「業務アプリケーション２（２６）」を「業務アプリケーション（ワープロ）（２６）」に、「業務アプリケーション１（４８）」を「業務アプリケーション（監視機能）（４８）」に変更した流れになる。
【００４１】
以上述べたように、本実施例によれば、業務アプリケーションごとに再起動レベルを設定しておくことにより、ある業務アプリケーションにエラーが発生した場合に、エラーを発生した当該業務アプリケーションの設定されている再起動レベルに応じて、自動的に再起動，終了など行うようにし、システム全体をハングアップさせることなく業務を継続することができる。
【００４２】
【発明の効果】
本発明によれば、無人運用を行っている装置で業務アプリケーションエラーが発生した場合でも装置自身で再立ち上げまたは当該業務アプリケーションのみの終了を判定し、処理することでエラー発生後もハングアップすることなく継続して業務を行うことが可能になり、従来、無人運用を行っている装置で業務アプリケーションエラーが発生した場合、エラーが発生した時点でシステムがハングアップしてしまい、以降の業務を継続することができなかったという問題を解消できる。
【図面の簡単な説明】
【図１】本発明を適用する第１の実施例のシステム構成図である。
【図２】本発明の第１の実施例に係るソフトウェア構成図である。
【図３】本発明の第１の実施例に係るプライオリティテーブルの構造図である。
【図４】本発明の第１の実施例に係るアプリケーションエラー管理テーブルの構造図である。
【図５】本発明の第１の実施例に係るシステム自動再立ち上げの流れを説明するための図である（自身の業務アプリケーションのみを終了する場合）。
【図６】本発明の第１の実施例に係るシステム自動再立ち上げの流れを説明するための図である（自身の業務アプリケーションのみを再起動する場合）。
【図７】本発明の第１の実施例に係るシステム自動再立ち上げの流れを説明するための図である（ＯＳを含めて再起動する場合）。
【図８】本発明を適用する第２の実施例のシステム構成図である。
【図９】本発明の第２の実施例に係るソフトウェア構成図である。
【図１０】本発明の第２の実施例に係るプライオリティテーブルの構造図である。
【図１１】本発明の第２の実施例に係るアプリケーションエラー管理テーブルの構造図である。
【符号の説明】
１…勘定系ホスト（ホストシステム）、
１Ａ〜１Ｂ…監視サーバ、
２…ＩＳＤＮ、
２Ａ〜２Ｂ…監視クライアント、
３，３Ａ，３Ｂ…ルータ、
４…営業店サーバ、
５…営業店端末、
６Ａ〜６Ｃ…現金自動取引装置、
７Ａ〜７Ｂ…流通ソフトウェア、
８Ａ〜８ｎ…業務アプリケーション、
９…ミドルソフトウェア群、
１０…アプリケーションエラー検知プロセス、
１１…再起動要否判定プロセス、
１２…ロギングファイル、
１３…プライオリティテーブル、
１４…アプリケーションエラー管理テーブル、
１５…オペレーティングシステム（ＯＳ）、
５０…支店監視装置。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a system automatic restart control method for an apparatus equipped with a plurality of programs (business applications, etc.) And system automatic restart system In particular, the system automatic restart control method that makes it possible to continue the processing of the subsequent system as much as possible without causing the entire apparatus to hang up. And system automatic restart control system About.
[0002]
[Prior art]
As a conventional technique, restarting of the apparatus has been realized by providing a check means and a counter outside the apparatus as disclosed in Japanese Patent Application Laid-Open No. 56-4848. Further, a technique for detecting a failure at the time of executing an application, such as “JP-A-56-127256”, or “JP-A-5-233341”, does not repeat the restart after detecting an application failure indefinitely. Although there is technology, for the detection of application failure within one device, a series of restarting methods based on automatic determination at the priority level of whether or not the application needs to be restarted was not considered .
[0003]
[Problems to be solved by the invention]
In the conventional technique, business application error detection is performed by an external device, and the importance of the business application is not taken into consideration, and after the business application error is detected, restart is performed unconditionally.
The present invention detects a program error in an apparatus and automatically restarts the program or terminates the program according to the level of the program in which the error has occurred when the program error is detected. ) The purpose is to continue the processing of the subsequent system as much as possible without causing the entire system to hang up.
[0004]
[Means for Solving the Problems]
In order to achieve the above object, the present invention registers the restart level at the time of error occurrence in the priority storage means (priority table 13) for each program installed in the apparatus. When an error occurrence is detected by the error occurrence detection means (application error detection process 10) when the program is executed, the restart level for the program in which the occurrence of the error is detected is determined by referring to the priority storage means, and the restart is performed. Restart the system based on the level. As the restart level, a level that defines whether to restart including the operating system (OS), to restart only its own program, or to end its own program can be considered.
By adopting this configuration, a restart level can be set according to the importance of the program, and the optimum system can be automatically restarted or the program can be terminated according to the contents. The subsequent processing can be continued without causing unnecessary hang-up in the system.
[0005]
DETAILED DESCRIPTION OF THE INVENTION
Examples of the present invention will be described below. The present invention can be applied to all programs (software). However, in the following description, a business application will be mainly described as a program.
(First embodiment)
First, a first embodiment of the present invention will be described with reference to FIGS.
In this embodiment, the present invention is applied to various business applications of an automatic teller machine. FIG. 1 is a system configuration diagram of this embodiment, FIG. 2 is a software configuration diagram of this embodiment, and FIG. FIG. 4 is a structural example of an application error management table, and FIGS. 5 to 7 are diagrams for explaining the flow of system automatic restart control according to the present embodiment.
[0006]
FIG. 1 shows the configuration of a general bank system.
In the figure, 1 is a billing host that is a center side configuration, 2 is an ISDN (Integrated Services Digital Network), 3 is a router, 4 is a sales office server (relay server) that is a sales office side configuration, and 5 is a sales office terminal. , 6A-6B are automatic teller machines.
[0007]
The account system host system (1) includes account processing of various transactions performed by the end user at the store terminal (5) and the automatic cash transaction apparatuses (6A to 6B), the store terminal (5) and the automatic cash transaction apparatus (6A). To 6B) is a host system for instructing withdrawing or printing. When the branch office server (4) sends a message to the host system (1) without permission from each branch terminal (5) or the automated teller machine (6A-6B), the host system (1) side This is a relay server that controls each device in the sales office and transmits / receives information to / from the host system via the router (3). As a result, the host system (1) is managed as a communication device in units of the sales office server (4).
[0008]
FIG. 2 is a diagram illustrating a software configuration example of the automatic teller machine (6A to 6B) in the present embodiment.
The software configuration includes an operating system (15), which is basic software for operating the apparatus, an application error detection process (10) for determining whether application error detection and restart are necessary, and a restart necessity determination process ( 11) including middle software group (9), business application group (8A-8B) for processing various transactions performed in automatic teller machines (6A-6B), and other distribution software group (7A-7B) Priority table (13) necessary for restart determination, logging file (12) for registering error contents when an application error is detected, and error count and restart count when an application error occurs Application error management table ( 4) because to be composed.
[0009]
FIG. 3 is a diagram showing an example of the structure of the priority table (13).
As shown in the figure, the priority table (13) includes an “application name” (16) for registering an application name to be monitored and a “process” for registering a main process name for application error detection and hang-up detection. A “restart level” (18) for registering the “name” (17), and the execution level (level for restarting including the OS or restarting only its own business application) at the time of restarting When restarting, a “restart count” (19) that is registered to prevent falling into an endless loop.
[0010]
Further, the setting contents of the first column “No. 0” (20) of the priority table (13) are positioned as areas for all applications. The setting values of the restart level (21) of all application target areas are “0” (enable the setting values of each business application) and “1” (unconditionally restart the OS when an application error is detected) ) Two setting methods are provided. In the case of FIG. 3, the restart level is “0” and the number of restarts is “3”.
[0011]
In addition, three setting methods “A”, “B”, and “C” are provided as setting values of the restart level (22) of each business application target area. Here, “A” means “restart including OS”, “B” means “end only its own business application”, “C” means “only its own business application” It means “Restart”.
[0012]
FIG. 4 is a diagram showing an example of the structure of the application error management table (14).
As shown in the figure, the application error management table (14) is automatically reflected by registering the application name to be monitored (application name) (16) (this name is registered in the priority table (13)). The number of times an application error has occurred (24) for managing the number of times an application error has occurred, and the number of restart executions (25) for holding the number of times of restart.
[0013]
If the restart level is set to the restart level for all business application targets and each business application target, the restart execution count (14) in the application error management table (14) in FIG. 25) is updated by +1. When an application error is detected again after performing the restart process for the number of times set in “Restart Count” (19), a message is displayed indicating that error factors need to be removed by maintenance personnel and a monitoring system Is also notified.
[0014]
FIG. 5 is a diagram illustrating an example of system automatic restart when only the business application of itself is terminated. First, the function sharing of each process is explained.
In the figure, the business application 2 (26) is an application that operates on the automatic teller machine (6A to 6B), and the restart level of the priority table (13) has “B”, and only that application is terminated. However, it is an application that does not particularly adversely affect the function of the automatic cash transaction apparatus (6A to 6B) as a whole (for example, even if the application for processing the deposit transaction is terminated in the automatic cash transaction apparatus, withdrawal and other transactions) Is not affected).
[0015]
The system management process (27) acquires the processing contents and error contents notified from the restart necessity determination process (29) in the logging file (12), and performs processing such as an end instruction to each application, system restart, etc. I do. The application error detection process (28) is a process for monitoring the state of the application registered in the priority table (13). The restart necessity determination process (29) determines by referring to the priority table (13) whether or not to restart according to the “application error occurrence notification” notified from the application error detection process (28). This process notifies the system management process (27) of the result.
[0016]
In this example, an application error occurs in the business application 2 (26) in which the restart level (18) of the priority table (13) is set to “B (end only its own business application)” (step 30). The application error detection process (28) detects the error (step 31). The application error detection process (28) notifies the restart necessity determination process (29) of the application name in which the error has occurred (step 32). The restart necessity determination process (29) that has received the error notification searches the priority table (13) and determines the processing (step 33). The restart necessity determination process (29) notifies the determination result to the system management process (27) as an “application termination instruction” (step 34).
[0017]
Upon receiving the instruction, the system management process (27) acquires the name of the business application in which the application error has occurred, the content of the error occurrence, etc. in the logging data acquisition process (step 35) in the logging file (12) (step 36), and then the application (Step 37, step 38). As a result, only the business application in which an error has occurred is terminated (step 39), and a series of flows is completed.
[0018]
FIG. 6 is a diagram illustrating an example of automatic system restart when only the own business application is restarted.
In this example, the distribution software 2 (40) is an application for displaying various information on the automatic teller machines (6A to 6B) through the Internet or the like, and the restart level of the priority table (13) has “C”. For example, if an error occurs during the time period in which only the service is operated (such as midnight), the service cannot be provided as an automated teller machine (6A-6B), so the application is restarted. And ready for service. The function sharing of other processes is the same as that described in FIG.
[0019]
In this example, an application error occurs in the distribution software 2 (40) in which the restart level of the priority table (13) is set to “C (restart only its own business application)” (step 30). The generated error is detected by the application error detection process (28) (step 31). The business application 2 (26) is operating normally.
[0020]
The application error detection process (28) notifies the restart necessity determination process (29) of the application name in which the error has occurred (step 32). The restart necessity determination process (29) that has received the error notification searches the priority table (13) and determines the processing (step 33). In this example, since the restart level is set to “C”, that is, to restart only its own application, first, the number of restart executions (25) in the application error management table (14) is updated by +1 (step 41). And store again (step 42).
[0021]
Next, the restart count (19) set in the priority table (13) is compared with the restart count (25) in the application error management table (14) (step 43), and the restart count (25). Is less than the number of restarts (19), an application restart instruction is notified to the system management process (27) (step 44). Upon receiving the instruction, the system management process (27) acquires the name of the business application in which the application error has occurred, the content of the error occurrence, etc. in the logging data acquisition process (step 35) in the logging file (12) (step 36), and then the application After the end processing (step 37, step 38) is performed, the application is restarted in the application restart processing (step 45). As a result, the business application is restarted (step 47), completing a series of flows.
[0022]
The result of comparing the restart count (19) set in the priority table (13) with the restart count (25) of the application error management table (14) (step 43), the restart count (25) If the number is greater than the number of restarts (19), an application termination instruction is notified to the system management process (27) (step 34). The system management process (27) having received the instruction acquires the name of the business application in which the application error has occurred, the content of the error occurrence, and the like in the logging file (12) in the logging data acquisition process (step 35) (step 36). Application termination processing is performed (steps 37 and 38). As a result, only the business application in which the error has occurred is terminated (step 39).
[0023]
Note that the number of restart executions (25) in the application error management table (14) can be “cleared to 0” by an operation by maintenance personnel or the like. When the number of restarts is exceeded as described above, a message indicating that work such as removal of error factors by maintenance personnel is necessary is displayed.
[0024]
FIG. 7 is a diagram illustrating an example of automatic system restart when restarting including the OS.
The business application 1 (48) is an important application for linking the business application group and the middle software group, and the restart level of the priority table (13) has “A”, and an error occurs in the application. In such a case, the operation as an automatic cash transaction apparatus (6A to 6B) becomes unstable, which may affect various transactions. The function sharing of other processes is the same as that described in FIG.
[0025]
In this example, an application error occurs in the business application 1 (48) set as “A (restart including OS)” in the priority table (13) (step 30), and the error is detected as an application error. The process (28) detects (step 31). The business application 2 (26) is operating normally. The application name in which an error has occurred is notified to the restart necessity determination process (29) (step 32). The restart necessity determination process 29 that has received the error notification searches the priority table (13) and determines the processing (step 33). In this example, since the restart level (18) of the priority table (13) is “A” and it is set to restart including the OS, the number of restart executions (25) in the application error management table (14) is first set. ) Is updated by +1 (step 41) and stored in the application error management table (14) (step 42).
[0026]
Next, the restart count (19) set in the priority table (13) is compared with the restart count (25) of the application error management table (14) (step 43), and the restart count (25) is compared. Is less than the number of restarts, a system restart instruction is notified to the system management process (27) (step 49). The system management process (27) that has received the instruction obtains the name of the business application in which the application error has occurred, the content of the error occurrence, etc. in the logging file (12) by the logging data acquisition process (step 36), and then terminates its own system. All business applications are terminated (step 39) in the process (step 50) and each application termination process (step 37, step 38). Thereafter, the system itself is restarted (step 51), each business application is also started (step 52), and a series of flows is completed.
[0027]
The result of comparing the restart count (19) set in the priority table (13) with the restart count (25) of the application error management table (14) (step 43), the restart count (25) If the number is greater than the number of restarts (19), an application termination instruction is notified to the system management process (27) (step 34). The system management process (27) that has received the instruction obtains the name of the business application in which the application error has occurred, the content of the error occurrence, and the like in the logging file (12) in the logging data acquisition process (step 36), and then terminates the application. Perform (step 37, step 38). As a result, only the business application in which the error has occurred is terminated (step 39).
[0028]
Note that the number of restart executions (25) in the application error management table (14) can be “cleared to 0” by an operation by maintenance personnel or the like. If the number of restarts is exceeded as described above, a message indicating that work such as removal of error factors by maintenance personnel is necessary is displayed.
[0029]
Next, a second embodiment of the present invention will be described. In this embodiment, the present invention is applied to a business application such as word processing software or spreadsheet software.
FIG. 8 is a system configuration diagram of the present embodiment, FIG. 9 is a software configuration diagram of the present invention, FIG. 10 illustrates an example structure of a priority table, and FIG. 11 illustrates an example structure of an application error management table. . Components similar to those in the first embodiment are denoted by the same reference numerals.
[0030]
In FIG. 8, 1A to 1B are monitoring servers having a monitoring center side configuration, 2 is an ISDN, 3A and 3B are routers, 6A to 6C are automatic cash transaction devices, 2A to 2B are monitoring clients, and 50 is a branch monitoring device. .
[0031]
The monitoring server (1A to 1B) and the monitoring client (2A to 2B) are systems for monitoring the operating status of the automatic teller machines (6A to 6C) in the time zone when the business office is unattended, such as early morning, night, and holidays. . The branch monitoring device (50) is a device for monitoring the operating status of the automatic teller machine (6A to 6C) by a salesclerk in a time zone when the sales office is manned, and the sales office is unmanned. In the time zone, it has a function of transmitting the failure information of the automatic teller machines (6A to 6C) to the center side system via the router (3A to 3B).
[0032]
FIG. 9 is a software configuration diagram of the branch monitoring device (50), and shows an operating system (15) for operating the device, an application error detection process (10) for detecting an application error, and whether restart is necessary. Necessary for the restart determination process (11) for determining, the business application (8A) for monitoring the operating status of the automatic teller machine, the other business application groups (8B to 8n), and the restart determination. A priority table (13), a logging file (12) for registering error contents when an application error is detected, and an application error management table for holding the number of errors and restart times when an application error occurs (14).
[0033]
FIG. 10 is a diagram illustrating a structure example of the priority table (13) in the present embodiment.
As shown in the figure, the priority table (13) in this embodiment includes a business application name (16) to be monitored, a main process name (17) to be detected for application error detection and hangup, and a restart. Reboot level (18) when performing a restart (restart level that specifies whether to restart including the OS or only its own business application) and fall into an endless loop when performing a restart In order to prevent this, it is composed of the number of restarts (19) registered. The first item “No. 0” (20) is positioned as an area to be set for all business applications.
[0034]
In the priority table (13), the setting value of the restart level (18) of all business application target areas is “0” (enables the setting value of each business application) and “1” (unconditionally when an application error is detected) To restart the system including the OS). In addition, the setting values of the restart level (18) of each business application target area are “A” (restart including the OS), “B” (end only its own business application), “C” ( (Restart only your own business application).
[0035]
In the example of FIG. 10, the restart level (18) of the business application name “monitoring function” is “A”, and the restart level (18) of the application “word processor” operated by the operator to create a report or the like. “B”, the restart level (18) of the application “Spreadsheet” operated by the operator to create an estimate or the like is set to “C”.
[0036]
FIG. 11 is a diagram illustrating a structure example of the application error management table (14).
As shown in the figure, the application error management table (14) is a restart execution holding the business application name (16) to be monitored, the number of occurrences of application errors (24), and the number of restarts. Number of times (25).
[0037]
In the priority table (13), when the restart level of all business application target areas is “1” and the restart level of each business application target area is set to “A” (in this example, “monitoring” "Function") updates the number of restart executions (25) in the application error management table (14) of FIG. 11 by +1 each time the restart process is performed. If an application error is detected again after performing the restart process for the set number of times, a message is displayed indicating that error factors need to be removed by maintenance personnel.
[0038]
10 and 11, when an error occurs in the business application (word processor), the restart level (18) of the priority table (13) is "B", so that it has been described with reference to FIG. Only the own business application (word processor) is terminated by the same flow. However, in FIG. 5, “business application 2 (26)” is changed to “business application (word processor) (26)”.
[0039]
Further, when an error occurs in the business application (spreadsheet), the restart level (18) of the priority table (13) is “C”, so that the own flow is similar to that described in FIG. Restart only business applications (spreadsheets). In this case, for example, in FIG. 6, “business application 2 (26)” is changed to “business application (word processor) (26)”, and “distributed software 2 (40)” is changed to “business application (spreadsheet) (40)”. Changed flow.
[0040]
Further, when an error occurs in the monitoring function, the restart level (18) of the priority table (13) is “A”, so the restart is performed including the OS in the same flow as described in FIG. To do. In this case, for example, in FIG. 6, “business application 2 (26)” is changed to “business application (word processor) (26)”, and “business application 1 (48)” is changed to “business application (monitoring function) (48)”. Changed flow.
[0041]
As described above, according to this embodiment, by setting a restart level for each business application, when an error occurs in a business application, the business application in which the error occurred is set. Depending on the restart level, the system can be restarted or terminated automatically, and business can be continued without hanging up the entire system.
[0042]
【The invention's effect】
According to the present invention, even when a business application error occurs in an unattended operation device, the device itself determines whether to restart or terminate only the business application, and hangs up even after the error occurs by processing. In the past, when a business application error occurred on a device that was operating unattended, the system would hang up when the error occurred. The problem of being unable to continue can be solved.
[Brief description of the drawings]
FIG. 1 is a system configuration diagram of a first embodiment to which the present invention is applied.
FIG. 2 is a software configuration diagram according to the first embodiment of the present invention;
FIG. 3 is a structural diagram of a priority table according to the first embodiment of the present invention.
FIG. 4 is a structural diagram of an application error management table according to the first embodiment of the present invention.
FIG. 5 is a diagram for explaining the flow of system automatic restart according to the first embodiment of the present invention (when only its own business application is terminated);
FIG. 6 is a diagram for explaining the flow of automatic system restart according to the first embodiment of the present invention (in the case where only its own business application is restarted);
FIG. 7 is a diagram for explaining the flow of automatic system restart according to the first embodiment of the present invention (when restarting including the OS);
FIG. 8 is a system configuration diagram of a second embodiment to which the present invention is applied.
FIG. 9 is a software configuration diagram according to the second embodiment of the present invention;
FIG. 10 is a structural diagram of a priority table according to a second embodiment of the present invention.
FIG. 11 is a structural diagram of an application error management table according to the second embodiment of the present invention;
[Explanation of symbols]
1 ... Account host (host system),
1A to 1B ... monitoring server,
2 ... ISDN,
2A-2B ... monitoring client,
3, 3A, 3B ... router,
4 ... Sales office server,
5 ... Sales terminal,
6A-6C ... Automatic cash transaction equipment,
7A-7B ... Distribution software,
8A-8n ... business application,
9 ... Middle software group,
10 ... Application error detection process,
11 ... Reboot necessity determination process,
12 ... Logging file,
13 ... Priority table,
14 ... Application error management table,
15 ... Operating system (OS),
50: Branch monitoring device.

Claims

In the system automatic restart control method in an apparatus equipped with a plurality of programs,
Priority storage means for storing the restart level at the time of error occurrence and a predetermined number of restarts for each program;
An error occurrence detection means for detecting the occurrence of an error during program execution;
A program error management means for recording the number of restarts for each program,
When an error occurrence of the first program is detected by the error occurrence detection means, the system is restarted including the operating system (OS) stored as the restart level of the priority storage means for the first program. Based on the level, the level for restarting only its own program, the level for restarting only its own program, the level for restarting the system including the OS, and the level for restarting only its own program . to restart the program to determine the cornerstone,
When it is determined that it is necessary to restart the first program, the number of restarts of the program error management means for the first program is updated,
For the first program, compare the predetermined number of restarts of the priority storage means and the number of restarts of the program error management means,
An automatic system restart control method, wherein the first program is restarted when the number of restart executions is equal to or less than a predetermined number of restarts.

In the automatic restart control system that controls the automatic restart of multiple installed programs,
Priority storage means for storing a restart level at the time of occurrence of an error and a predetermined number of restarts for each program;
An error occurrence detection means for detecting the occurrence of an error during program execution;
Program error management means for recording the number of restarts performed for each program,
When a program error is detected by the error occurrence detection means, the system restarts the system including the operating system (OS) stored as the restart level of the priority storage means, and only its own program is restarted. levels, based on the level to terminate only own programs, and means for discriminating the necessity to restart of the program when a level to restart only level and own program to restart the system, including the OS,
A means for updating the number of restarts of the program error management means when it is determined that restart is required for the program in which the error has been detected by the error occurrence detection means;
Means for comparing a predetermined number of restarts of the priority storage means with the number of restarts of the program error management means for a program in which an error has been detected by the error occurrence detection means;
And a means for restarting the program when it is necessary to restart the program in which the error has been detected by the error occurrence detection means and the number of restart executions is less than or equal to the predetermined number of restarts. Automatic restart control system.