JPH09305440A - エラー処理方法 - Google Patents

Abstract

(57)【要約】 【課題】 本発明は、マルチタスクモニタやオペレーテ
ィングシステム上で動作する複数のプロセスからなる処
理装置において、エラー処理の簡潔化、エラー処理によ
る負荷の軽減と運用管理プロセスの異常終了によって装
置が制御不能になる状況を回避することを目的としてい
る。 【解決手段】 エラー監視を行う監視プロセスと、複数
の被監視プロセスと、を有し、エラー発生時に前記被監
視プロセスから前記監視プロセスに通知すべき情報を前
記被監視プロセスでのエラー発生前に予め保持し、前記
被監視プロセスでのエラー発生後に前記情報を前記監視
プロセスに通知する、構成とした。また、監視プロセス
によるエラー監視実行中に監視プロセスの異常終了が検
出された場合には、システムリセットを実行し再び監視
プロセスを起動する構成とした。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、マルチタスクのモ
ニタやオペレーティングシステム上で動作する、複数の
処理単位（タスクまたはプロセス）から構成される装置
におけるエラー処理方法に関するものである。

【０００２】

【従来の技術】マルチタスク環境上で動作する複数の処
理単位から構成される装置においてては、各処理単位
（プロセス）は、外部からのイベント受信を待ち、受信
後にその処理を行うという動作をくり返すようになって
いる。この種の装置のエラー処理方法は、被エラー監視
プロセスがエラーを検知すると、エラー監視プロセスに
対して、プロセス間通信等の手段によりエラー通知が行
うようになっている。

【０００３】以下、従来のエラー処理方法を具体的に図
９、図１０を用いて説明する。図９はエラー監視プロセ
スの処理フローを示し、図１０は被エラー監視プロセス
の処理フローを示している。

【０００４】図９において、監視プロセスは、イベント
の受信待ちの状態で待機し（ステップ９０１）、イベン
トが受信されると受信イベントが被エラー監視プロセス
からのエラー通知メッセージか否かをチェックし（ステ
ップ９０２）、エラー通知であれば適切なエラー処理を
実行した後（ステップ９０３）、イベントの受信待ちの
状態に復帰する（ステップ９０１）。

【０００５】受信イベントが通常のイベントであれば受
信イベントの処理を実行する（ステップ９０４）。

【０００６】通常のイベント処理実行後、一定時間が経
過したか否かをチェックし（ステップ９０５）、一定時
間が経過していない場合は、ステップ９０１に復帰し、
一定時間が経過していた場は、エラー監視となる全ての
プロセス（Ｎ個）に対してその状態をチェックする以下
の処理を実行する（ステップ９０６以下）。

【０００７】まず、カウンタＩを初期化し（ステップ９
０６）、カウンタ値がＮ以下であることを確認した後、
カウンタＩをインクリメントし（ステップ９０７、ステ
ップ９０８）、被エラー監視プロセスに状態チェックメ
ッセージを送信し（ステップ９０９）、そのメッセージ
に対するレスポンス受信を待つ（ステップ９１０）。そ
の後、エラーを報告するメッセージを受信した場合や、
レスポンス待ちのタイムアウトが発生した場合には（ス
テップ９１１）、適切なエラー処理を行う（ステップ９
１２）。また、ステップ９０９で正常なレスポンスを受
信した場合もステップ９１０からステップ９０７へジャ
ンプする。

【０００８】以上一連の処理をカウンタＩがＮに達する
まで繰り返し、全ての被エラー監視プロセスに対する処
理が終了した場合には、再びイベント受信待ちの状態に
復帰する（ステップ９０１）。

【０００９】一方、エラー監視の対象である、被エラー
監視プロセスの処理は、以下のとおりである。図１０に
おいて、被エラー監視プロセスはイベントの受信待ちの
状態で待機し（ステップ１００１）、イベントが受信さ
れると、そのイベントがエラー監視プロセスからの状態
チェックメッセージか否かをチェックする（ステップ１
００２）。

【００１０】発生したイベントが、エラー監視プロセス
からの状態チェックメッセージでない場合には、通常の
イベント処理を実行し（ステップ１００３）、更に、そ
の通常のイベント処理において障害が発生しているか否
かをチェックし（ステップ１００４）、正常であればイ
ベント受信待ちの状態に復帰する（ステップ１００
１）。障害が検知された場合には、監視プロセスに対し
てエラー通知メッセージを送信し（ステップ１００
５）、適切なエラー処理を実行した後（ステップ１００
６）、イベント受信待ちの状態に復帰する（ステップ１
００１）。

【００１１】逆に、発生したイベントが、エラー監視プ
ロセスからの状態チェックメッセージである場合には、
被エラー監視プロセスはその状態情報を監視プロセスに
送信する処理を行う（ステップ１００７）。

【００１２】この様に、エラー監視プロセスが、定期的
にエラー監視の対象となる全てのプロセスに対して状態
チェックメッセージを送信し、これを受信した被エラー
監視プロセスが状態情報を監視プロセスに送信するよう
な監視形態ととる理由は、例えば、被エラー監視プロセ
スのプログラムの不具合等により、エラーの検出自体を
行なえずプロセスが異常終了してしまい異常終了を監視
プロセスに通知することができないという事態を回避す
るためである。

【００１３】

【発明が解決しようとする課題】しかし、上述の従来技
術の構成では、エラーを検出するために監視対象となる
プロセスと監視プロセスとがメッセージを交換する必要
があるため、本来の処理のほかにプロセス間通信処理部
やタイマー処理を組み込まなければならず、ソフトウエ
アの処理が複雑になる。

【００１４】また、監視プロセスが定期的に全ての監視
対象プロセスに対して状態チェックメッセージを送信す
るため、特に監視対象数が大きい場合は計算資源が無駄
に使用されることとなる。

【００１５】また、装置管理機能を持つ監視プロセスが
異常終了した場合には、他のプロセスが監視プロセスの
異常終了を検知し、エラー処理を行わない限り、装置全
体が制御不能になるという問題がある。この問題に対し
て、監視プロセスの障害検知をメッセージによる通知方
式で行う場合には、各監視対象プロセスが逆に監視プロ
セスに対して状態チェックメッセージを送信することに
なり、ソフトウエアがますます複雑化し、負荷もさらに
大きくなることとなる。

【００１６】本発明は、上述の課題に鑑みて為されたも
ので、マルチタスクモニタやオペレーティングシステム
上で動作する複数のプロセスからなる処理装置におい
て、エラー処理の簡潔化、エラー処理による負荷の軽減
と運用管理プロセスの異常終了によって装置が制御不能
になる状況を回避すること、を目的としている。

【００１７】

【課題を解決するための手段】上述の課題を解決するた
め、本発明は、エラー監視を行う監視プロセスと、複数
の被監視プロセスと、を有し、エラー発生時に前記被監
視プロセスから前記監視プロセスに通知すべき情報を前
記被監視プロセスでのエラー発生前に予め保持し、前記
被監視プロセスでのエラー発生後に前記情報を前記監視
プロセスに通知する構成とした。また、監視プロセスに
よるエラー監視実行中に監視プロセスの異常終了が検出
された場合には、システムリセットを実行し再び監視プ
ロセスを起動する構成とした。

【００１８】この構成により、監視プロセスが定期的に
被監視プロセスの状態をチェックする必要がなくなり、
エラー処理部のプログラム量を飛躍的に減らすことが可
能になり、また、エラー検知にプロセス間通信を使用し
ないので装置の計算資源の浪費を避けることができる。
また、運用管理プロセスの異常終了によって装置が制御
不能になる状況を回避することができる。

【００１９】

【発明の実施の形態】請求項１記載の発明は、エラー監
視を行う監視プロセスと、複数の被監視プロセスと、を
有し、エラー発生時に前記被監視プロセスから前記監視
プロセスに通知すべきエラー情報を前記被監視プロセス
でのエラー発生前に予め保持し、前記被監視プロセスで
のエラー発生後に前記情報を前記監視プロセスに通知す
るものであり、エラー検出に必要な情報を被監視プロセ
スとは異なる場所に保持しておき事後的に監視プロセス
に通知することにより被監視プロセスが異常終了した場
合でも確実にエラー検出を行ない得る。

【００２０】請求項２記載の発明は、請求項１におい
て、システム起動時に呼出されエラー情報を保持する領
域を書込み可能な状態にする使用開始手段を有するもの
であり、これによりシステム起動時に際しては確実にエ
ラーチェックの準備が整うことになる。

【００２１】請求項３記載の発明は、請求項１におい
て、エラー発生の際に前記被監視プロセスから前記監視
プロセスに通知すべきエラー情報を保持する処理を被監
視プロセス起動時に実行する登録手段を有するものであ
り、被監視プロセス起動の際にエラー通知に必要な情報
の登録が実行されるため、被監視プロセス起動直後にそ
のプロセスのエラー監視が可能になる。

【００２２】請求項４記載の発明は、請求項１におい
て、監視プロセスにより起動された後命令受付け待ちの
状態で待機し、エラー情報認識後にそのエラー情報を読
み出して前記監視プロセスに通知する監視手段を有する
ものであり、監視手段がエラー検出を開始、続行するた
め、監視手段を呼出すだけで全ての監視対象プロセスで
生じたエラーを検知することが可能となる。

【００２３】請求項５記載の発明は、請求項４におい
て、エラー発生による被監視プロセス終了時にエラー情
報を監視手段に認識させる使用終了手段を有するもので
あり、監視手段を実行させることにより、エラー通知に
必要な情報を被監視プロセス終了時に確実に監視プロセ
スに通知することが可能となる。

【００２４】請求項６記載の発明は、請求項４におい
て、監視プロセスにより起動され監視手段に対して監視
停止命令を通知して監視を終了させる監視停止手段を有
するものであり、監視手段によりエラー監視を開始し、
監視終了手段によりエラー監視を中断でき、監視不要な
処理に対してのエラー監視、エラー通知を避けることが
可能となる。

【００２５】請求項７記載の発明は、請求項５におい
て、監視プロセスが通常のイベント処理を実行するスレ
ッドとエラー監視処理を実行するスレッドとを有して構
成されるものであり、監視プロセス１０６がエラー監視
をする処理としない処理を明確に区別することが可能に
なるため、エラー監視をしない処理において、不必要な
エラー処理を実行する必要がなくなる。

【００２６】請求項８記載の発明は、エラー監視プロセ
スと、複数の被監視プロセスと、を有し、この複数の被
監視プロセスの異常終了状態を各々検出し、前記被監視
プロセスが異常終了した場合に起動し異常終了した被監
視プロセスを特定する情報を前記エラー監視プロセスに
通知するエラー処理を実行するものであり、被監視プロ
セスが異常終了した場合でも確実にエラー検出、エラー
通知を行ない得る。

【００２７】請求項９記載の発明は、エラー監視を行う
監視プロセスと、複数の被監視プロセスと、これらのプ
ロセスに対応して各々設けられプロセス実行開始時にオ
ープン状態となりプロセス実行停止時にクローズ状態と
なるデバイスファイルと、を有し、前記いずれかのプロ
セスが異常終了しデバイスファイルがクローズ状態とな
った場合にその異常プロセスを特定する情報を前記監視
プロセスに通知するものであり、被監視プロセスの状態
監視用のデバイスファイルによりエラー検知を確実に行
ない得る。

【００２８】請求項１０記載の発明は、請求項８又は請
求項９において、監視プロセスによるエラー監視実行中
にエラー制御手段が監視プロセスの異常終了を検出した
場合には、システムリセットを実行し再び監視プロセス
を起動するものであり、監視プロセスが監視中に異常終
了した場合に装置全体が再起動するので、必要となるプ
ロセスを全て再生でき、監視プロセスがなく装置の操作
が不能になるという状況をなくすることが可能である。

【００２９】以下、本発明の実施の形態を図面を参照し
て具体的に説明する。図１は、本発明のエラー制御デバ
イスを使用したＦＡＸ情報サービス装置のソフトウエア
構成を示している。１０１はＦＡＸ情報サービス装置で
あり、このＦＡＸ情報サービス装置１０１のメモリ空間
は、後に詳述するように、複数のプロセスが実行される
ユーザ空間１０２と、基本オペレーティングシステム
（以下、ＯＳという）が実行される基本ＯＳ空間１０３
と、から構成されている。更に、この基本ＯＳ空間１０
３では、エラー制御デバイスドライバ１０４とそれ以外
のデバイスドライバ１０５、例えば、複数チャネルファ
クシミリ通信ボードドライバ等との双方が動作し、ユー
ザ空間１０２では、監視プロセス１０６とポート制御プ
ロセス（１０７〜１０９）との双方が動作するようにな
っている。

【００３０】さて、ＦＡＸ情報サービス装置１０１は、
電話回線と１対１に対応するＮ個のポート制御プロセス
（１０７から１０９）を有し、複数のファクシミリ文書
を複数の情報ボックス（図示せず）に分類して蓄積して
いる。ポート制御プロセス（１０７から１０９）はユー
ザから来る呼の着信を待ち、着呼後にユーザが所定の情
報ボックスの情報の取出しの指示をした場合には、ＰＢ
トーン等で受信し、指定された情報ボックスに蓄積され
たファクシミリ文書を送信する制御を行う。ユーザが情
報ボックスへの登録を指示した場合には、ポト制御プロ
セスはファクシミリ画像を受信し、指定の情報ボックス
に蓄積する制御を行う。

【００３１】このポート制御プロセス（１０７〜１０
９）が動作中にエラー発生を検出した場合には、各々の
ポート制御プロセス（１０７〜１０９）に対応して設け
られた被監視デバイスファイル（１１０〜１１２）にア
クセスしてエラー通知を行なう。一方、監視プロセス１
０６はＦＡＸ情報サービス装置の起動、停止処理を行う
他に、監視デバイスファイル１１０にアクセスしてポー
ト制御プロセスの実行監視を行うようになっている。

【００３２】エラー制御デバイスドライバ１０４は、基
本ＯＳ空間１０３に、作業領域として監視デバイスファ
イル１１０に対応する監視デバイスワークメモリ１１４
と、被監視デバイスファイル（１１０〜１１２）に対応
する被監視デバイスワークメモリ（１１５〜１１７）を
有し、これらのワークメモリは、それぞれ対応するデバ
イスファイルの状態を記述する領域を有している。ＦＡ
Ｘ情報サービス装置１０１が起動するときに、基本ＯＳ
はエラー制御デバイス１０４の初期化処理を呼び出し、
前記初期化処理はワークメモリ（１１４〜１１７）を割
り当て、各ワークメモリの状態フィールドをクローズに
設定する。

【００３３】また、エラー処理デバイスドライバ１０４
は、使用開始手段１１８と、監視手段１１９と、監視停
止手段１２０と、登録手段１２１と使用終了手段１２２
とを有しており、使用開始手段１１８は対応するデバイ
スファイルがオープンされたときに基本ＯＳにより呼び
出され、使用終了手段１２２は対応するデバイスファイ
ルがクローズされたときに基本ＯＳにより呼び出される
プログラムであり、また、監視手段１１９と監視停止手
段１２０と登録手段１２１とは、基本ＯＳが提供するシ
ステムコール（以下では入出力制御命令と呼ぶ）により
実行される固有のプログラムである。

【００３４】以上のようなソフトウエア構成を採るＦＡ
Ｘ情報サービス装置におけるエラー制御デバイスドライ
バによるエラー処理フローを図２乃至図８を用いて説明
する。

【００３５】最初に使用開始手段１１８について説明す
る。使用開始手段１１８は、エラー制御デバイスドライ
バの一部を構成するプログラムであり、システムが立ち
上がり、いずれかのプロセスが開始されてデバイスファ
イルがオープンされた時に基本ＯＳにより呼出され、そ
のプロセスに対応するデバイスファイルのワークメモリ
（１１４〜１１７）の状態フィールドをオープン状態に
するものである。図２は、その動作の詳細フローを示し
ている。

【００３６】監視プロセス１０６またはポート制御プロ
セス（１０７〜１０９）が、それぞれ、監視デバイスフ
ァイル１１３または被監視デバイスファイル（１１０〜
１１２）をオープンしたときに、基本ＯＳはオープンさ
れたそのデバイスファイルをパラメータとして、エラー
制御デバイスドライバ１０４の使用開始手段１１８を呼
び出す。

【００３７】使用開始手段１１８は、パラメータで指定
されたデバイスファイルが監視デバイスファイル１１３
かどうかをチェックし（ステップ２０１）、監視デバイ
スファイル１１３であれば、既に監視デバイスファイル
１１３がオープンされているか否かを監視デバイスワー
クメモリ１１４の状態フィールドを参照することにより
チェックする。その状態フィールドがオープンの状態で
あれば、既に他のプロセスが監視デバイスファイルをオ
ープンしているということなので、ステップ２０３でエ
ラーをリターンする。逆に、その状態フィールドの値が
クローズであれば、ステップ２０４で状態フィールドを
オープンに設定し、ステップ２０５にて成功をリターン
する。

【００３８】パラメータ指定のデバイスファイルが監視
デバイスファイル１１３でなければ、被監視デバイスフ
ァイル（１１０〜１１２）であるので、ステップ２０６
において前記ファイルのデバイス番号をチェックする。
デバイス番号が不正であればエラーをリターンするが
（ステップ２０８）、デバイス番号が正しければ、その
デバイスファイルに対応するワークメモリ（１１５〜１
１７）の状態フィールドをチェックする（ステップ２０
９）。その状態フィールド値がオープンであればエラー
をリターンし（ステップ２０８）、クローズであればそ
の状態フィールドをオープンに更新して（ステップ２１
０）、成功をリターンする（ステップ２１１）。

【００３９】以上一連の処理が使用開始手段１１８の動
作であり、これにより、監視デバイスファイル１１３及
び実行される被監視デバイスファイル（１１０〜１１
２）のワークメモリ（１１４〜１１７）がオープン状態
となり、エラー処理の監視プロセスの実行準備が整う。

【００４０】次に、監視手段１１９及び監視停止手段１
２０について説明する。監視手段１１９及び監視停止手
段１２０は、エラー制御デバイスドライバ１０４の一部
を構成するプログラムであり、システム起動時に、監視
プロセス１０６により基本ＯＳを介して呼出され、その
間被監視デバイスファイル（１１０〜１１２）のエラー
監視を実行するものである。

【００４１】図３は、監視手段１１９の動作の詳細フロ
ーを示している。監視プロセス１０６がオープンした監
視デバイスファイル１１３に対して入出力制御コールを
実行して監視手段１１９を呼び出すと、基本ＯＳは、監
視デバイスファイル１１３とその監視デバイスファイル
１１３が指定した受信バッファアドレスをパラメータと
して監視手段１１９を実行する。

【００４２】まず、監視手段１１９は、パラメータで指
定されたデバイスファイルが監視デバイスファイル１１
３かどうかをチェックし（ステップ３０１）、監視デバ
イスファイル１１３でなければエラーをリターンする
（ステップ３０２）。監視デバイスファイル１１３であ
れば、監視デバイスワークメモリ１１４の状態フィール
ドを監視中に設定するとともに（ステップ３０３）、受
信バッファアドレスを指定アドレスに設定して受信待ち
状態に入りエラー検出を待つ（ステップ３０４）。

【００４３】この受信バッファに何等かの入力があれば
待ち状態を終了し実行状態に入り、監視デバイスワーク
メモリ１１４の状態フィールドを再びオープン状態に設
定した後（ステップ３０５）、受信バッファの内容を参
照し監視停止手段が実行されたかどうかを判断する（ス
テップ３０６）。受信バッファに後述の監視停止手段１
２０からの監視停止命令が設定されている場合は、監視
停止をリターンし（ステップ３０７）、受信バッファに
監視停止命令ではなくエラー情報が設定されていれば成
功をリターンする（ステップ３０８）。このエラー検出
後の処理は監視プロセス１０６が行なう。

【００４４】図４は監視停止手段１２２の動作の詳細フ
ローを示している。監視プロセス１０６がオープンした
監視デバイスファイル１１３に対して、監視停止手段１
２０を指定した入出力制御コールを実行すると、基本Ｏ
Ｓは監視デバイスファイル１１３をパラメータとして監
視停止手段１２０を実行する。監視停止手段１２０は、
パラメータで指定されたデバイスファイルが監視デバイ
スファイル１１３であるか否かをチェックし（ステップ
４０１）、監視デバイスファイル１１３でなければエラ
ー処理とし（ステップ４０２）、監視デバイスファイル
１１３であれば監視デバイスワークメモリ１１４の状態
フィールド値が監視中であるかチェックする（ステップ
４０３）。状態フィールド値が監視中でなければエラー
処理とし（ステップ４０２）、監視中であれば監視デバ
イスワークメモリ１１４のバッファアドレスフィールド
で指定された受信バッファに監視停止をライトし（ステ
ップ４０４）、基本ＯＳインターフェースであるＷＡＫ
ＥＵＰ処理をコールして（ステップ４０５）、受信待ち
の状態になっている監視手段１１９を待ち状態から監視
停止状態に変更し、成功をリターンする（ステップ３０
７）。

【００４５】以上一連の処理が監視手段１１９及び監視
停止手段１２０の動作であり、エラー監視が必要な処理
に対して監視手段１１９の起動をかけるだけで、エラー
が検出されるか監視停止処理が実行されるまでエラー監
視が続行されることとなる。また、監視停止処理も監視
手段１１９とは独立のプログラムである監視停止手段１
２０により実行される。

【００４６】次に、登録手段１２１について説明する。
登録手段１２１は、エラー制御デバイスドライバ１０４
の一部を構成し、エラー監視の対象となるポート制御プ
ロセス（１０７乃至１０９）の起動時に、各プロセスを
特定するための情報を基本ＯＳ空間上のワークメモリに
登録しておくためのプログラムであり、図５は、その動
作の詳細フローを示している。

【００４７】ポート制御プロセス（１０７乃至１０９）
がオープンされた被制御デバイスファイル（１１０〜１
１２）に対して入出力制御コールを実行し、登録手段を
呼び出すと、基本ＯＳは、被制御デバイスファイル（１
１０〜１１２）とポート制御プロセス（１０７乃至１０
９）が提供するプロセスＩＤとポート番号とを含む情報
を受信する受信バッファのアドレスをパラメータとして
登録手段１２１を呼び出す。登録手段１２１は、パラメ
ータのデバイスファイルが被監視デバイスファイル（１
１０〜１１２）か否かをチェックし（ステップ５０
１）、被監視デバイスファイル（１１０〜１１２）でな
い場合はエラー処理をし（ステップ５０２）、被監視デ
バイスファイル（１１０〜１１２）である場合は、その
デバイスファイルの番号をチェックする（ステップ５０
３）。デバイスファイル番号が不正であればエラー処理
をし（ステップ５０２）、デバイスファイル番号が正し
ければ、前記受信バッファの内容を対応する被監視デバ
イスワークメモリ（１１５乃至１１７のメモリのうち１
つ）にコピーして成功をリターンする（ステップ５０
４、テスップ５０５）。

【００４８】以上一連の処理が登録手段１２１の動作で
あり、エラーが発生するプロセスを特定する情報を基本
ＯＳのワークエリア上に予め記述しておくことにより、
監視プロセスがエラー発生時にその情報を受け取り、エ
ラー個所を認識できることになる。

【００４９】次に、使用終了手段１２２について説明す
る。使用終了手段１２１は、エラー制御デバイスドライ
バ１０４の一部を構成するプログラムであり、いずれか
のプロセスが終了しデバイスファイルがクローズした時
に基本ＯＳにより呼出され、そのプロセスに対応するデ
バイスファイルのワークメモリ（１１４〜１１７）の状
態フィールドをクローズ状態にして、エラー発生プロセ
スを特定する情報を監視手段１１９の受信バッファにコ
ピーすることにより、スリープ状態にあった監視手段１
１９を実行状態にするものである。既に説明したよう
に、この監視手段１１９によりエラー情報が監視プロセ
ス１０６に通知されることでエラー検出が行なわれる。
図６はその動作の詳細フローを示している。

【００５０】監視プロセス１０６またはポート制御プロ
セス（１０７〜１０９）が、それぞれ、オープン中の監
視デバイスファイル１１０または被監視デバイスファイ
ル（１１０〜１１２）をクローズしたときに、基本ＯＳ
はそのデバイスファイルをパラメータとして、エラー制
御デバイスドライバ１０４の使用終了手段１２２を呼び
出す。使用終了手段１２２は、クローズされたデバイス
ファイルが被監視デバイスファイル１１３かどうかをチ
ェックする（ステップ６０１）。

【００５１】クローズされたデバイスファイルが、被監
視デバイスファイル（１１０〜１１２）でない（監視デ
バイスファイルである）場合は、監視デバイスワークメ
モリ１１４の状態フィードルが監視中であるか否かをチ
ェックし（ステップ６１０）、監視中でなければ成功を
リターンする（ステップ６１１）一方、監視中であれば
基本ＯＳのリブートインターフェースによりＦＡＸ情報
サービス装置１０１をリブートする（ステップ６１
２）。

【００５２】このシステムリブート（ステップ６１２）
が実行されるのは、監視中の監視プロセス１０６が何ら
かの障害により異常終了し、その際基本ＯＳによってオ
ープン状態であった監視デバイスファイル１１３がクロ
ーズされる場合である。このように、監視中の監視プロ
セス１０６が異常終了したときに、エラー制御デバイス
ドライバ１０４が装置をリセットする機能を設け、装置
リブートの際に監視プロセスを自動的に立ち上げるよう
に設定することにより、監視プロセスの存在を定期的に
ウオッチする処理と、監視プロセスが異常終了した際の
エラー処理を別途設けることなく、システムが制御不能
な状態で放置されるという状況を防止することが可能と
なる。

【００５３】次に、クローズされたデバイスファイルが
被監視デバイスファイル（１１０〜１１２）である場合
について説明する。使用終了手段１２２は、デバイス番
号のチェックを行い（ステップ６０２）、デバイス番号
が不正であればエラー処理を行ない（ステップ６０
３）、デバイス番号が正しければクローズされたデバイ
スファイルに対応する被監視デバイスワークメモリ（１
１５から１１７のうちの１つ）の状態フィールドをクロ
ーズに設定し（ステップ６０４）、監視デバイスワーク
メモリ１１４の状態フィールドが監視中か否かをチェッ
クする（ステップ６０５）。監視デバイスワークメモリ
１１４の状態フィールドが、監視中でない場合は、成功
をリターンし（ステップ６０８）、監視中である場合
は、監視デバイスワークメモリ１１４の受信バッファア
ドレスフィールドで指定されている受信バッファに、ク
ローズされた被監視デバイスファイル（１１０〜１１
２）に対応する被監視デバイスワークメモリ（１１５か
ら１１７のうちの１つ）に格納されている情報（例え
ば、プロセスＩＤとポート番号）をコピーした後（ステ
ップ６０６）、基本ＯＳインターフェースであるＷＡＫ
ＥＵＰをコールし（ステップ６０７）、受信待ちの状態
になっている監視手段１１９を待ち状態から実行状態に
変更し、成功をリターンする（ステップ６０８）。

【００５４】以上一連の処理が使用終了手段１２２の動
作であるが、このように、被監視デバイスファイル（１
１０〜１１２）がクローズされるのは、ポート制御プロ
セス（１０７〜１０９）がエラーを検知して前記デバイ
スファイルをクローズする場合と、当該プロセスが例外
等で異常終了し、基本ＯＳがオープン状態にある前記デ
バイスファイルをクローズする場合と、がある。前者の
場合には通常のエラー処理が実行されるが、後者のよう
に、監視対象のポート制御プロセス（１０７〜１０９）
が異常終了した場合であっても、既に説明した登録手段
により被監視デバイスワークメモリ（１１５〜１１７）
に予め格納してある情報が監視デバイスファイル１１３
に必ず登録されるため、障害情報を確実に監視プロセス
に通知することが可能となる。

【００５５】従って、監視プロセスが定期的に被監視プ
ロセスの状態をチェックする必要がなくなり、エラー処
理部のプログラム量を飛躍的に減らすことが可能にな
る。また、エラー検知にプロセス間通信を使用しないの
で装置の計算資源の浪費を避けることができる。

【００５６】以上のようなソフトウエア構成をもつエラ
ー制御デバイスドライバを使用して、監視プロセス１０
６がポート制御プロセス（１０７〜１０９）の状態監
視、エラー処理を実行するフローを、図７を用いて具体
的に説明する。この監視プロセス１０６は、ＦＡＸ情報
サービス装置１０１の起動、停止、ポート制御プロセス
（１０７〜１０９）の状態監視を行い、ポート制御プロ
セスが異常終了した場合、エラー処理として前記プロセ
スの再起動等を実行するようになっている。

【００５７】まず、システムの起動処理が実行されると
（ステップ７０１）、ポート制御プロセス（１０７〜１
０９）を必要数（電話回線数）起動するとともに、監視
デバイスファイル１１３をオープンして（ステップ７０
２）、エラー監視用スレッドを生成する（ステップ７０
３）。生成されたメインスレッドでは、ステップ７１２
以下の監視プロセス１０６本来の処理、つまり、システ
ム停止イベントの処理を実行する。イベント受信待ちの
状態で（ステップ７１２）、イベントを受信すると、そ
の受信イベントがシステム停止か否かをチェックし（ス
テップ７１３）、それがシステム停止イベントでない場
合にはイベントの処理（通常の処理）を実行して（ステ
ップ７１４）、再びイベント受信待ちの状態に復帰する
（ステップ７１２）。受信イベントがシステム停止イベ
ントである場合には、、監視停止手段を指定した入出力
制御コールを発行して監視停止手段により監視処理を停
止し（ステップ７１５）、システム停止処理を実行し
（ステップ７１６）、監視プロセスを停止する（ステッ
プ７１７）。

【００５８】一方、生成されたサブスレッドでは以下の
処理が実行される。エラーが発生した場合の障害情報を
受け取るバッファアドレスをパラメータとして、監視手
段を指定した入出力制御コールを発行して監視手段１１
９を呼出し（ステップ７０５）、エラーが発生するのを
待つ。ポート制御プロセス（１０７〜１０９）が異常終
了した場合と監視プロセス１０６が監視停止手段１２０
を呼び出した場合には、監視手段１１９は待ち状態から
実行状態に遷移し、ステップ７０５から処理が再開され
る。

【００５９】次いで、監視手段１１９は重大なエラーが
発生したのかを、ファクシミリ通信ボードのハードウエ
ア等をアクセスしてチェックする（ステップ７０６）。
重大エラーが発生した場合には装置の運用を停止するた
めに、システム停止イベントをメインスレッドに送信し
（ステップ７０７）、エラー監視スレッドを終了する
（ステップ７０８）。

【００６０】ステップ７０６でのチェックの結果、受信
したエラーが重大エラーでないならば、監視停止手段が
実行されたのかをチェックし（ステップ７０９）、監視
停止が実行されたのであればスレッドを終了する（ステ
ップ７１０）。また、監視停止が実行されたのではな
く、受信したエラーが復旧可能なエラーである場合は、
復旧処理を行った後（ステップ７１１）、ステップ７０
５にジャンプしてエラー監視を続行する。復旧処理は、
例えば、障害により制御プロセスが停止したポート番号
を受信バッファから参照し、そのポートのポート制御プ
ロセスを再起動することにより行なう。

【００６１】以上一連の処理が監視プロセス１０６の動
作であるが、このように監視プロセス１０６全体をメイ
ンスレッドとサブスレッドに分割し、通常のイベント処
理とシステム停止処理とをメインスレッドで実行する一
方、監視手段１１９を呼出してエラー検出をしエラーリ
カバリを実行する処理をサブスレッドで実行することに
より、監視プロセス１０６がエラー監視をする処理とし
ない処理とを明確に区別することが可能になるため、エ
ラー監視をしない処理において、不必要なエラー処理を
設ける必要がなくなる。更に、サブスレッドで監視手段
１１９を呼び出す（ステップ７０５）のみでエラー監視
が可能となり、プロセス間通信等を使用して定期的に被
監視プロセスの異常終了を検知をする必要がなくなるた
め、エラー検知処理部が非常に簡素化される。

【００６２】次に被監視プロセスであるポート制御プロ
セス（１０７〜１０９）の処理フローについて説明す
る。図８は、ポート制御プロセス（１０７〜１０９）の
エラー通知フローを示している。まず、制御する通信ポ
ートの初期化処理を行い（ステップ８０１）、制御する
ポート番号を獲得して被監視デバイスファイル（１１０
〜１１２）をオープンする（ステップ８０２）。次い
で、登録すべき情報の一つであるプロセスＩＤを基本Ｏ
Ｓから獲得し（ステップ８０３）、入出力制御コールを
基本ＯＳに発行して登録手段を呼び出す（ステップ８０
４）。更に、本来の処理であるファクシミリ通信処理を
実行した後（ステップ８０５）、エラーチェックを行い
（ステップ８０６）、エラーがない場合には、通常処理
である通信処理（ステップ８０５）を繰り返す。

【００６３】エラーを検知した場合には、被監視デバイ
スファイル（１１０〜１１２）をクローズし（ステップ
８０７）、ポート制御プロセス（１０７〜１０９）を終
了する（ステップ８０８）。このクローズ処理（ステッ
プ８０７）により図６の使用終了手段１２２が呼び出さ
れ、ステップ８０４で登録手段１２１に登録しておいた
情報が監視プロセスのバッファにコピーされ（ステップ
６０６）、監視手段を実行状態に設定する（ステップ６
０７）、ことによりエラー情報が監視プロセス１０６に
通知される。

【００６４】以上一連の処理がポート制御プロセス（１
０７〜１０９）の動作であり、クローズ処理により障害
情報を監視プロセスに通知するようにしたことにより、
例外等が発生し被監視プロセスが消滅した場合において
も、基本ＯＳがオープンされている被監視デバイスファ
イルをクローズするので、使用終了手段が確実にコール
され、監視プロセスに障害情報が確実に通知される。従
って監視プロセスが被監視プロセスの実行状況を定期的
にプロセス間通信等により監視する必要がなくなり、エ
ラー処理部が非常に簡単となり、さらに、計算資源の浪
費を押さえることができることとなる。

【００６５】

【発明の効果】以上の説明から明らかなように、本発明
により、監視プロセスが定期的に被監視プロセスの状態
をチェックすることなく、確実簡易にエラー通知を行う
ことが可能となるため、エラー処理部のプログラム量を
飛躍的に減らすことが可能になり、また、エラー検知に
プロセス間通信を使用しないので装置の計算資源の浪費
を避けることができる。

【００６６】更に、具体的には、エラー検出に必要な情
報を被監視プロセスとは異なる場所に保持しておき事後
的に監視プロセスに通知することにより被監視プロセス
が異常終了した場合でも確実にエラー検出を行ない得
る。 また、システム起動時に際しては確実にエラーチ
ェックの準備が整うことになり、被監視プロセス起動直
後にそのプロセスのエラー監視が可能になる。

【００６７】また、エラー通知に必要な情報を被監視プ
ロセス終了時に確実に監視プロセスに通知することが可
能となる。

【００６８】また、監視手段がエラー検出を開始、続行
するため、監視手段を呼出すだけで全ての監視対象プロ
セスで生じたエラーを検知することが可能となる。

【００６９】また、監視手段によりエラー監視を開始
し、監視終了手段によりエラー監視を中断でき、監視不
要な処理に対してのエラー監視、エラー通知を避けるこ
とが可能となる。

【００７０】また、エラー監視をする処理としない処理
を明確に区別することが可能になるため、エラー監視を
しない処理において、不必要なエラー処理を実行する必
要がなくなる。

【００７１】また、被監視プロセスが異常終了した場合
でも確実にエラー検出、エラー通知を行ない得る。

【００７２】また、被監視プロセスの状態監視用のデバ
イスファイルの利用によりエラー検知を確実に行ない得
る。

【００７３】更に、リセットにより必要となるプロセス
を全て再生できるので、監視プロセスがなく装置の操作
が不能になるという状況をなくすることが可能となる。

【図面の簡単な説明】

【図１】本発明のエラー制御デバイスドライバを使用し
たＦＡＸ情報サービス装置ソフトウエア構成図

【図２】本発明のエラー制御デバイスドライバの使用開
始手段詳細フロー図

【図３】本発明のエラー制御デバイスドライバの監視手
段詳細フロー図

【図４】本発明のエラー制御デバイスドライバの監視停
止手段詳細フロー図

【図５】本発明のエラー制御デバイスドライバの登録手
段詳細フロー図

【図６】本発明のエラー制御デバイスドライバの使用終
了手段詳細フロー図

【図７】本発明の監視プロセスの処理フロー図

【図８】本発明のポート制御プロセスの処理フロー図

【図９】従来例によるエラー監視プロセスの詳細フロー
図

【図１０】従来例による被エラー監視プロセスの詳細フ
ロー図

【符号の説明】

１０４ エラー制御デバイスドライバ １０６ 監視プロセス １０７ ポート制御プロセス １０８ ポート制御プロセス １０９ ポート制御プロセス

Claims (10)

【特許請求の範囲】
1. 【請求項１】 エラー監視を行う監視プロセスと、複数
   の被監視プロセスと、を有し、エラー発生時に前記被監
   視プロセスから前記監視プロセスに通知すべきエラー情
   報を前記被監視プロセスでのエラー発生前に予め保持
   し、前記被監視プロセスでのエラー発生後に前記エラー
   情報を前記監視プロセスに通知することを特徴とするエ
   ラー処理方法。
2. 【請求項２】 システム起動時に呼出されエラー情報を
   保持する領域を書込み可能な状態にする使用開始手段を
   有することを特徴とする請求項１記載のエラー処理方
   法。
3. 【請求項３】 エラー発生の際に前記被監視プロセスか
   ら前記監視プロセスに通知すべきエラー情報を保持する
   処理を被監視プロセス起動時に実行する登録手段を有す
   ることを特徴とする請求項1記載のエラー処理方法。
4. 【請求項４】 監視プロセスにより起動された後命令受
   付け待ちの状態で待機し、エラー情報認識後にそのエラ
   ー情報を読み出して前記監視プロセスに通知する監視手
   段を有することを特徴とする請求項1記載のエラー処理
   置方法。
5. 【請求項５】 エラー発生による被監視プロセス終了時
   にエラー情報を監視手段に認識させる使用終了手段を有
   することを特徴とする請求項４記載のエラー処理方法。
6. 【請求項６】 監視プロセスにより起動され監視手段に
   対して監視停止命令を通知して監視を終了させる監視停
   止手段を有することを特徴とする請求項４記載のエラー
   処理方法。
7. 【請求項７】 監視プロセスが通常のイベント処理を実
   行するスレッドとエラー監視処理を実行するスレッドと
   を有して構成されることを特徴とする請求項５記載のエ
   ラー処理方法。
8. 【請求項８】 エラー監視プロセスと、複数の被監視プ
   ロセスと、を有し、この複数の被監視プロセスの異常終
   了状態を各々検出し、前記被監視プロセスが異常終了し
   た場合に起動し異常終了した被監視プロセスを特定する
   情報を前記エラー監視プロセスに通知するエラー処理を
   実行することを特徴とするエラー処理方法。
9. 【請求項９】 エラー監視を行う監視プロセスと、複
   数の被監視プロセスと、これらのプロセスに対応して各
   々設けられプロセス実行開始時にオープン状態となりプ
   ロセス実行停止時にクローズ状態となるデバイスファイ
   ルと、を有し、前記いずれかのプロセスが異常終了しデ
   バイスファイルがクローズ状態となった場合にその異常
   プロセスを特定する情報を前記監視プロセスに通知する
   ことを特徴とするエラー処理方法。
10. 【請求項１０】 監視プロセスによるエラー監視実行中
    にエラー制御手段が監視プロセスの異常終了を検出した
    場合には、システムリセットを実行し再び監視プロセス
    を起動することを特徴とする請求項８又は請求項９記載
    のエラー処理方法。