(57)【要約】情報処理装置は、情報処理部と、情報処理部のリセットを検出する手段と、情報処理部からのログ情報を取得する取得手段と、取得手段が取得したログ情報を格納する少なくとも２面のバッファと、リセットの検出前または検出後に、ログ情報が所定以上取得されない条件が満たされたときに前記取得手段が取得したログ情報の格納先を前記少なくとも２面のバッファのいずれかの間で切り替える制御部と、を備える。
2013008281.tif 000002
【特許請求の範囲】
【請求項１】
情報処理部と、
前記情報処理部がリセットされたことを検出する手段と、
前記情報処理部のログ情報を取得する取得手段と、
前記取得手段が取得したログ情報を格納する複数のバッファと、
前記リセットの検出前または検出後に、前記ログ情報が取得されないときに、前記取得手段が取得したログ情報の格納先となるバッファを切り替える制御部と、を備える情報処理装置。
【請求項２】
前記制御部は、前記ログ情報が出力されない期間が所定時間経過したか否かを検知する手段と、
前記ログ情報が出力されない期間が所定時間経過した場合、ログ情報が出力される前に前記リセットが検出されたときに、前記ログ情報の格納先を切り替える手段と、を有する請求項１に記載の情報処理装置。
【請求項３】
前記制御部は、前記リセット検出後から所定の期間の経過前に、前記ログ情報が出力されないときに前記ログ情報の格納先を切り替える手段を有する請求項１または２に記載の情報処理装置。
【請求項４】
前記情報処理部からのタイマ初期化信号を所定周期で受信するとともに、前記所定周期内に前記タイマ初期化信号を受信できないときに前記所定周期の時間が経過したことを示す契機信号を発生する契機信号発生部をさらに備え、
前記制御部は、前記契機信号にしたがって前記ログ情報の格納先を切り替える手段を有する請求項１から３のいずれか１項に記載の情報処理装置。
【請求項５】
コンピュータが、
情報処理部がリセットされたことを検出するステップと、
前記情報処理部のログ情報を取得する取得ステップと、
前記取得したログ情報を複数のバッファのいずれかに格納するステップと、
前記リセットの検出前または検出後に、前記ログ情報が取得されないときに、前記取得手段が取得したログ情報の格納先となるバッファを切り替える制御ステップと、を実行する情報処理方法。
【請求項６】
前記制御ステップは、前記ログ情報が出力されない期間が所定時間経過したか否かを検知するステップと、
前記ログ情報が出力されない期間が所定時間経過した場合、ログ情報が出力される前に前記リセットが検出されたときに、前記ログ情報の格納先を切り替えるステップと、を有する請求項５に記載の情報処理方法。
【請求項７】
前記制御ステップは、前記リセット検出後から所定の期間の経過前に、前記ログ情報が出力されないときに前記ログ情報の格納先を切り替えるステップを有する請求項５または６に記載の情報処理方法。
【請求項８】
前記制御ステップは、前記情報処理部からのタイマ初期化信号を所定周期で受信するとともに、前記所定周期内に前記タイマ初期化信号を受信できないときに前記所定周期の時間が経過したことを示す契機信号を受けるステップと、
前記契機信号にしたがって前記ログ情報の格納先を切り替えるステップと、を有する請求項５から７のいずれか１項に記載の情報処理方法。  
【請求項９】
コンピュータに、
情報処理部がリセットされたことを検出するステップと、
前記情報処理部のログ情報を取得する取得ステップと、
前記取得したログ情報を複数のバッファのいずれかに格納するステップと、
前記リセットの検出前または検出後に、前記ログ情報が取得されないときに前記取得手段が取得したログ情報の格納先となるバッファを切り替える制御ステップと、を実行させるためのプログラム。
【請求項１０】
前記制御ステップは、前記ログ情報が出力されない期間が所定時間経過したか否かを検知するステップと、
前記ログ情報が出力されない期間が所定時間経過した場合、ログ情報が出力される前に前記リセットが検出されたときに、前記ログ情報の格納先を切り替えるステップと、を有する請求項９に記載のプログラム。
【請求項１１】
前記制御ステップは、前記リセット検出後から所定の期間の経過前に、前記ログ情報が出力されないときに前記ログ情報の格納先を切り替えるステップを有する請求項９または１０に記載のプログラム。
【請求項１２】
前記制御ステップは、前記情報処理部からのタイマ初期化信号を所定周期で受信するとともに、前記所定周期内に前記タイマ初期化信号を受信できないときに前記所定周期の時間が経過したことを示す契機信号を受けるステップと、
前記契機信号にしたがって前記ログ情報の格納先を切り替えるステップと、を有する請求項９から１１のいずれか１項に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置のログの処理に関するものである。
【背景技術】
【０００２】
コンピュータのシステムコンソールは、例えば、シリアルポートでコンピュータに接続されたテキスト出力装置である。システムコンソールを単にコンソールという。コンピュータは、コンソールにシステム管理用のメッセージを出力する。システム管理用のメッセージは、コンソールログと呼ばれる。コンソールログには、コンピュータ起動時のメッセージ、Operating System（ＯＳ）起動後、種々の要因で発生するＯＳからのメッセージ、アプリケーションプログラムからのメッセージ等が含まれる。すなわち、コンソールログは、通常の操作結果、例えば、ＯＳのローディングあるいは、シャットダウン等におけるメッセージ、コンピュータの障害発生時にＯＳあるいはBasic Input/Output System（ＢＩＯＳ）が出力する障害メッセージ等を含む。【０００３】
ＯＳは、ローディング後には、コンピュータの状態に応じて出力されるシステムログを収集する。しかし、ＯＳのローディング、あるいはシャットダウン時といったＯＳとＢＩＯＳの間で処理の引継ぎが発生する場面において、ＯＳがシステムログとして収集できないメッセージが出力される。このようなシステムログに収集されないメッセージであっても、コンソールログには出力される。したがって、システム管理上、コンソールログは、重要である。【０００４】
コンソールログは、例えば、チップセット上のシリアルコンソールポートに、キャラクタデータとして出力される。出力されたコンソールログは、出力バッファ上でバッファリングされ、保持される。ただし、コンソールログのバッファサイズは有限である。したがって、コンソールログがバッファ容量の限界まで蓄積された場合には、例えば、最も古いデータが、より新しいデータによって上書きされる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００５−２９２９３２号公報
【特許文献２】特開平９−６６５１号公報
【特許文献３】特開平１１−３１０９１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、実際に障害が発生した場合においては、障害の発生状況を示すメッセージが以下の要因によって上書きされ、コンソールログを活用できない場合がある。なお、障害の発生状況を示すメッセージを含むコンソールログを障害ログと呼ぶことにする。また、以下の要因はコンソールログに限られず、ログの格納先の容量が有限なコンピュータシステムでのログ取得時に生じ得る。
（ａ）ＯＳ以外のアプリケーションにより多量メッセージが出力されることがある。
（ｂ）ユーザ操作やシステム動作などによって、コンピュータが再起動し、再起動時のメッセージが出力される結果、バッファ上の障害ログが上書きされてしまうことがある。
（ｃ）コンピュータの使用状況により、バッファから障害ログを採取するまでに長時間経過することがある。その結果、コンピュータシステムの管理者、あるいは、障害解析のためのコンピュータプログラムが障害ログを採取する前に上記（ａ）（ｂ）が繰り返され、障害ログが上書きされることがある。【０００７】
一方、ログを蓄積するためのコンソールサーバを接続する、もしくはＬＡＮを経由して、コンソールデータを他のサーバに飛ばすＳｅｒｉａｌ  Ｏｖｅｒ  ＬＡＮ（ＳＯＬ）機能を使用し、他のサーバにログを蓄積するなど、コンソールログの保存方法は存在する。しかし、コンソールサーバあるいはＳＯＬでは専用装置を導入するため、保守費用の増加を伴う。また、コンソールサーバあるいはＳＯＬを導入したとしても、得られるログの大半は正常動作時の無用なログである場合が多い。したがって、コンソールサーバあるいはＳＯＬのような専用装置を配備しているユーザは少ない。また、障害の発生したコンピュータシステムから切り離されて障害ログが蓄積されるため、障害が発生したコンピュータと障害ログを結びつけるための仕組みが要求される。さらに、コンソールサーバあるいはＳＯＬのような専用装置で得られる大量のログから障害発生時のメッセージを特定する作業は、困難を伴う場合がある。【０００８】
以上の問題をまとめると以下の通りである。
（１）障害発生時に、コンピュータシステムからはコンソールログ等のログに、障害に関連するメッセージが出力される。しかし、ユーザ操作によるコンピュータシステムの起動操作、シャットダウン操作、障害復旧のためのシステム動作に等よりメッセージが出力されるため、障害に関連するメッセージが消えてしまう場合がある。
（２）ログ蓄積用の専用装置を具備すると、費用が増加する。
（３）障害発生時のログとその他のメッセージを識別するのが困難である。特に、今日のコンピュータシステムは、複数ベンダの装置、あるいは、コンピュータプログラムを含む。そして、異なるベンダが開発したＯＳ、ＢＩＯＳ、その他のコンピュータプログラムが出力する障害メッセージは多種多様である。このようなコンピュータシステムの様々なメッセージから障害発生時のログを特定し、摘出することは困難な場合がある。【０００９】
そこで、開示の技術の一側面は、コンピュータシステム等の情報処理装置において、障害発生時のログ消失を抑制できるようにすることを目的とする。
【課題を解決するための手段】
【００１０】
開示の技術の一側面は、以下の情報処理装置によって例示できる。本情報処理装置は、情報処理部と、情報処理部がリセットされたことを検出する手段と、情報処理部のログ情報を取得する取得手段と、取得手段が取得したログ情報を格納する複数のバッファと、リセットの検出前または検出後に、ログ情報が取得されないときに、前記取得手段が取得したログ情報の格納先となるバッファを切り替える制御部と、を備える。  
【発明の効果】
【００１１】
本情報処理装置によれば、障害発生時のログ消失を抑制できる。
【図面の簡単な説明】
【００１２】
【図１】実施例１に係る情報処理装置の構成を例示する図である。
【図２】ＩＰＭＣの構成を例示する図である。
【図３】ＷＤＴの構成を例示する図である。
【図４】コンソールデータ受信部の詳細構成を例示する図である。
【図５】サーバ停止処理実行時の処理フローを例示する図である。
【図６】サーバ起動時の処理フローを例示する図である。
【図７】ＷＤＴによるプログラムの異常発生を検知する処理フローを例示する図である。
【図８】通常稼働のシーケンスとシャットダウン時に異常が発生した場合のシーケンスとを比較して例示する図である。
【図９】情報処理装置の起動によるリセット後のシーケンスを例示する図である。
【図１０】ＷＤＴがＯＳまたはアプリケーションのフリーズ状態を検出した場合のシーケンスを例示する図である。
【図１１】ＩＰＭＣの制御部の処理フローを例示する図である。
【図１２】ＩＰＭＣの制御部の処理フローを例示する図である。
【図１３】実施例２に係るＩＰＭＣの構成を例示する図である。
【図１４】実施例２に係るコンソールデータ受信部の構成を例示する図である。
【図１５】通常稼働のシーケンスとシャットダウン時に異常が発生した場合のシーケンスとを比較して例示する図である。
【図１６】通常稼働のシーケンスと起動時に異常が発生した場合のシーケンスとを比較して例示する図である。
【発明を実施するための形態】
【００１３】
以下、図面を参照して本発明を実施するための最良の形態（以下、実施形態という）に係る情報処理装置について説明する。以下の実施形態の構成は例示であり、本情報処理装置は実施形態の構成には限定されない。
【実施例１】
【００１４】
図１から図１０の図面を参照して、実施例１に係る情報処理装置９を説明する。図１は、実施例１に係る情報処理装置９の構成を例示する図である。情報処理装置９は、例えば、サーバと呼ばれる情報処理機能を提供するコンピュータである。また、情報処理装置９は、複数のコンピュータによるコンピュータシステムであってもよい。また、情報処理装置９は、コンピュータシステムに含まれる１つのコンピュータ、例えば、ブレードサーバと呼ばれるものであってもよい。さらに、情報処理装置９は、コンソールログを出力する装置であれば、その種類は問わない。例えば、情報処理装置９は、パーソナルコンピュータであってもよい。【００１５】
図１のように、情報処理装置９は、Central Processing Unit（ＣＰＵ）と、メモリと、チップセット３と、チップセット３からのコンソールログのデータを受信するI/Oチップ４と、I/Oチップ４のシリアルコンソールポートからコンソールログのデータが出力されるコネクタ（ＲＪ４５コネクタ）５と、チップセット３からのコンソールログのデータを受信するIntelligent Platform Management Controller（ＩＰＭＣ）１と、Watchdog Timer（ワッチドッグタイマ、ＷＤＴ）２とを有している。ＩＰＭＣ１は、サーバブレード等のコンピュータのハードウェアあるいはファームウェアの動作を管理するマイクロコントローラである。【００１６】
チップセット３は、ＣＰＵ、メモリ等の各部間でのデータ授受に関わる処理を実行する。チップセット３は、例えば、入出力コントローラ等を含む。チップセット３は、例えば、Intel Architecture（ＩＡ）チップセットである。ただし、情報処理装置９のチップセット３が、ＩＡチップセットに限定される訳ではない。すなわち、情報処理装置９としての機能を提供できる構成であれば、どのようなチップセットであってもよい。チップセット３は、例えば、SPARCチップのアーキテクチャを含むものであってもよい。また、チップセット３は、機器組込用のプロセッサを含むものであってもよい。チップセット３、ＣＰＵ、およびメモリ等が情報処理部の一例である。【００１７】
図１の例では、チップセット３は、I/Oチップ４、ＩＰＭＣ１に対して、コンソールログのデータ、およびリセット信号を出力する。コンソールログのデータは、ＣＰＵ上のＯＳ、ＢＩＯＳ、ミドルウェア、アプリケーションプログラム等のコンピュータプログラムが出力するメッセージを含むデータある。リセット信号は、チップセット３に含まれるリセット回路がＣＰＵをリセットする信号である。リセット信号は、ＣＰＵの起動時に発せられ、ＣＰＵのハードウェアを初期状態にする。ＣＰＵは、リセット信号によって初期化された後に処理を開始し、例えば、ＢＩＯＳの起動、ＯＳのブート等を実行する。【００１８】
I/Oチップ４は、チップセット３からのコンソールログのデータを受信し、シリアルコンソールポートからＲＪ４５コネクタ５に出力する。I/Oチップ４としては、Super I/Oチップと呼ばれるものを例示できる。Super I/Oチップは、種々のシリアルインターフェース、パラレルインターフェース、各種デバイスへのインターフェース等を組み合わせた入出力インターフェースである。ただし、情報処理装置９において、I/Oチップ４がSuper I/Oチップに限定される訳ではない。また、コンソールログの出力経路が、I/Oチップ４とＲＪ４５コネクタ５に限定される訳ではない。例えば、テキスト情報をシリアルポートから出力できる仕様のものであれば、どのような構成でもよい。  【００１９】
ＩＰＭＣ１は、情報処理装置９、例えば、ブレードサーバのハードウェア、ファームウェアの動作を管理するマイクロコントローラである。ＩＰＭＣ１は、チップセット３からコンソールログのデータを受信し、保存する処理を実行する。ＩＰＭＣ１は、コンソールログのデータを受信するデータポート（Ｄａｔａ）と、リセット信号を受信するリセットポート（ＲＳＴ）を有する。図１の例では、チップセット３に対して、I/Oチップ４とＩＰＭＣ１とが並列に接続されている。しかし、情報処理装置９の構成が図１に限定される訳ではない。例えば、チップセット３に対して、I/Oチップ４とＩＰＭＣ１とが直列に接続されてもよい。例えば、ＩＰＭＣ１が、I/Oチップ４のシリアルポートからコンソールログのデータを受信するようにしてもよい。逆に、ＩＰＭＣ１が、I/Oチップ４にコンソールログのデータを引き渡すようにしてもよい。【００２０】
ＷＤＴ２は、チップセット３からの図示しないタイマ初期化信号を定期的に受けて、初期化される。そして、チップセット３からのタイマ初期化信号が所定期間受信できないときに、ＩＰＭＣ１に通知信号を送る。      【００２１】
さらに、図１では、情報書処理装置９は、上位装置と接続されている。上位装置は、例えば、情報処理装置９および他の情報処理装置等を管理する管理用コンピュータ等である。情報処理装置９は、上位装置とは、例えば、Network Interface Card（ネットワークカード、ＮＩＣ）、Fibre Channel （ファイバーチャネル）、InfiniBand（インフィニバンド）等の通信インターフェースで接続される。 【００２２】
なお、情報書処理装置９は、ハードディスク駆動装置等の外部記憶装置を有してもよい。また、情報書処理装置９は、ＣＤ、ＤＶＤ、ブルーレイディスク、フラッシュメモリカード等の着脱可能記憶媒体の駆動装置を有してもよい。【００２３】
図２に、ＩＰＭＣ１の構成を例示する。ＩＰＭＣ１は、コンソールデータ受信部１１と、切替スイッチ１２と、バッファ１３−０、１３−１と、ログ読み出しコマンド受信部１４とを有する。【００２４】
コンソールデータ受信部１１は、チップセット３からコンソールログのデータを受信し、切替スイッチ１２を介してバッファ１３−０またはバッファ１３−１に保存する。コンソールデータ受信部１１は、ＩＰＭＣ１のデータポート（Ｄａｔａ）へのコンソールログのデータ受信を監視し、受信したデータを取得する。また、コンソールデータ受信部１１は、リセットポートへのリセット信号（ＲＳＴ）の受信を監視する。ここで、リセット信号は、情報処理装置９が起動されたときにプロセッサが初期化されたことを示す。【００２５】
また、コンソールデータ受信部１１は、タイマ１１３を有し、コンソールログの受信中の期間、コンソールログを受信しない期間、コンソールログを受信していないことを確認後リセット信号発生までの期間、あるいは、リセット信号受信後などの期間を計時する。そして、コンソールデータ受信部１１は、例えば、コンソールログが所定期間取得されないときに切替スイッチ１２を制御してコンソールログのデータ格納先をバッファ１３−０とバッファ１３−１との間で切り替える。【００２６】
すなわち、コンソールデータ受信部１１は、コンソールログのデータ受信状態を監視し、データ受信が停止したこと、または受信データ量の変動が停止したこと等を契機にタイマ１１３により時間ｔ１、ｔ２等の計時をスタートする。以下、データ受信が停止したこと、または受信データ量の変動が停止したこと等を単にデータ変動の停止ともいう。【００２７】
時間ｔ１はデータ変動の停止を確定するために計時する時間であり、予め設定可能な閾値（以下、第１所定時間Ｔ１）を越えてデータの変動が停止するかどうかの判定のために用いられる。時間ｔ２はリセットの発生まで計時する時間である。時間ｔ２については、例えば、データの変動停止が確認できた後に計時を開始すればよい。そして、時間ｔ２は、データの変動停止後、予め設定可能な閾値（以下、第２所定時間Ｔ２）内にリセットが発生するかどうかを判定するために用いられる。【００２８】
さらに、コンソールデータ受信部１１には、Ｗａｔｃｈｄｏｇ  Ｔｉｍｅｒ（以下、ＷＤＴ２）からのトリガ信号が入力される。ＷＤＴ２は、例えば、ＯＳあるいはアプリケーションが異常となり、コンピュータがフリーズ状態となったことを検知するためのタイマである。【００２９】
ＷＤＴ２は、例えば、Intelligent Platform Management Interface（ＩＰＭＩ）の機能の１つとして提供される。ＩＰＭＩは、ハードウェアの構成やＯＳに依存することなく、サーバのハードウェア、あるいはネットワーク機器をモニタ可能にするための標準インターフェース仕様である。ただし、ＷＤＴ２がＩＰＭＩ仕様のものに限定される訳ではない。ＷＤＴ２は、契機信号発生部の一例である。【００３０】
ログ読み出しコマンド受信部１４は、チップセット３あるいは情報処理装置９の上位装置と接続されている。ログ読み出しコマンド受信部１４は、チップセット３のＣＰＵあるいは情報処理装置９の上位装置からログ読み出しコマンドを受信すると、バッファ１３−０あるいはバッファ１３−１のコンソールログをログ読み出しコマンド送信元に返信する。【００３１】
図３に、ＷＤＴ２の構成を例示する。ＷＤＴ２は、ＭＡＸ値から所定周期ごとに値を減算するカウンタを有している。ＷＤＴ２は、ＩＰＭＣ１およびチップセット３を介してＣＰＵ上のＯＳ３Ａからタイマ初期化信号を受け、カウンタをＭＡＸ値に設定する。そして、ＷＤＴ２は、次のタイマ初期化信号を受けるまで、カウンタ値の減算を繰り返す。そして、カウンタ値がプレタイムアウト値に達すると、ＷＤＴ２は、プレタイムアウト信号をＩＰＭＣ１に供給する。実施例１では、プレタイムアウト信号は、例えば、情報処理装置９、ＯＳ、あるいはアプリケーションのフリーズの検知に使用される。プレタイムアウト値が所定周期の一例であり、プレタイムアウト信号が契機信号の一例である。【００３２】
例えば、ＯＳあるいはアプリケーションに不具合が発生し、情報書処理装置９がフリーズすると、タイマ初期化信号がＷＤＴ２に供給されなくなる。すると、カウンタの減算が継続し、カウンタ値は、プレタイムアウト、さらにはタイムアウトとなる。タイムアウトとなると、タイムアウト信号がＩＰＭＣ１に出力され、ＩＰＭＣ１は、ＯＳ、アプリケーションの不具合発生を検知する。一方、カウンタ値の減算が繰り返し実行されている間に、ＷＤＴ２が次のタイマ初期化信号を受けると、ＷＤＴ２は、カウンタ値をＭＡＸ値に再度設定する。【００３３】
ＷＤＴ２の使用例としては、例えば、プレタイムアウトでＯＳへの割り込み等による監視対象での不具合発生の通知を例示できる。また、タイムアウトでリセット動作等による監視対象に対する復旧処理の起動が例示できる。以上のカウンタＭＡＸ値、プレタイムアウト値、タイムアウト値、ＯＳによるタイマ初期化信号の発生周期は、外部から設定可能である。【００３４】
コンソールデータ受信部１１は、ＩＰＭＣ１のＣＰＵが実行するコンピュータプログラム、ファームウェア等の動作によって実現される。以下、ＩＰＭＣ１のＣＰＵがコンソールデータ受信部１１として、コンピュータプログラム、ファームウェア等により処理を実行することを、コンソールデータ受信部１１が処理を実行するという。ただし、コンソールデータ受信部１１は、コンソールログのデータ受信回路、およびタイマ１１３を含む専用デジタル回路であってもよい。【００３５】
切替スイッチ１２は、切替スイッチ１２の接続先と同期した切替レジスタにレジスタビットを持ち、ビットの書き替えにより切替スイッチ１２の接続先を制御することが可能である。例えば、レジスタビット＝“０”のとき、コンソールデータ受信部１１とバッファ１３−０とが接続される。また、レジスタビット＝“１”のとき、コンソールデータ受信部１１とバッファ１３−１とが接続される。切替スイッチ１２は、コンピュータプログラムとしてのスイッチでもよいし、ハードウェアのスイッチでもよい。コンピュータプログラムとしてのスイッチとしては、例えば、メモリ、レジスタ等に設定されたビットを判定し、コンソールログの出力先をバッファ１３−０とバッファ１３−１との間で切り替える処理部を例示できる。また、ハードウェアのスイッチとしては、レジスタビットに応じて、接続先を切り替えるデジタル回路、あるいは、トランジスタ等を含む回路を例示できる。バッファ１３−０、１３−１は、例えば、ＩＰＭＣ１のメモリ上の領域である。ただし、バッファ数が２面に限定される訳ではない。【００３６】
より具体的には、コンソールデータ受信部１１は、切替スイッチ１２、およびバッファ１３−０、１３−１を用いて以下の処理を実行する。
（１）コンソールデータ受信部１１は、切替スイッチ１２により、バッファ１３−０と１３−１とを切り替えて、コンソールログのデータを保存する。通常のコンソールログは、１スクリーン分のデータは、８０文字×２５行＝２０４８Ｂである。実施例１では、バッファ１３−０、１３−１は、コンソールログ１スクリーン分より大きなデータとする。例えば、バッファ１３−０、１３−１は、それぞれ６５５３６（６４ＫＢ＝３２スクリーン分）とする。【００３７】
（２）コンソールデータ受信部１１は、例えば、バッファ１３−０を初期のコンソールログ格納エリアとする。したがって、情報処理装置９の通常動作状態では、コンソールデータはバッファ１３−０に記録されていくものとする。【００３８】
（３）バッファ１３−０、１３−１は受信したコンソールデータを初期アドレスより順次記録していき、記録したデータ量がバッファ容量の限界に達すると初期アドレスに戻って記録済みのデータに上書きしていくものとする。【００３９】
（４）切替スイッチ１２は、コンソールデータ受信部１１、すなわち、ＩＰＭＣ１のＣＰＵの接続先をバッファ１３−０、１３−１の間で切り替える。ただし、切替スイッチ１２は、３面以上のバッファを順次切り替えるようにしてもよい。【００４０】
（５）以上の構成を前提として、コンソールデータ受信部１１は、以下の機能を有する。
（ａ）コンソールデータ受信部１１は、データ受信の有無および受信データの変動の有無を検知する。そして、コンソールデータ受信部１１は、一定時間データの受信がない、もしくは受信データの変動がないことを検出する。ここで、受信データの変動がないとは、例えば、値０もしくは値１の受信データが継続して受信されることをいう。
（ｂ）コンソールデータ受信部１１は、情報処理装置９の再起動時に発生するリセット信号の発生を検知する。
（ｃ）コンソールデータ受信部１１は、（ａ）の発生から所定時間内に（ｂ）を検知した場合に切替スイッチ１２の切り替え契機を与える。より具体的には、コンソールデータ受信部１１は、例えば、切替スイッチ１２の切替レジスタのレジスタビットを反転する。
（ｄ）ＷＤＴ２におけるプレタイムアウトによるプレタイムアウト信号を受信した場合に、コンソールデータ受信部１１は、切替スイッチ１２の切り替え契機を与える。【００４１】
（６）コンソールデータ受信部１１が（３）にて設定したレジスタビットを元に切替スイッチ１２が接続先をバッファ１３−０とバッファ１３−１の間で切り替える。
（７）実施例１では、ＩＰＭＣ１は、格納したコンソールデータログを読み出すための別のポートを持ち、格納されたログはＯＳもしくは上位装置から読み出すことができる。【００４２】
（８）実施例１では、上の契機以外に、ＯＳもしくは上位装置からＩＰＭＣ１に対する専用コマンドを受信することにより切替スイッチ１２のレジスタビットを更新することによっても、面切替が実行できる。【００４３】
図４に、コンソールデータ受信部１１の詳細構成を例示する。コンソールデータ受信部１１は、データ受信状態検出部１１１と、制御部１１２と、タイマ１１３とを有する。データ受信状態検出部１１１は、ＩＰＭＣ１のデータポートで受信したコンソールログのデータを監視し、データ受信の有無および受信データの変動の有無を検知する。そして、データ受信状態検出部１１１は、受信したコンソールログのデータをそのまま切替スイッチ１２を通じてバッファ１３−０、１３−２に格納する。また、データ受信状態検出部１１１は、データ受信の有無および受信データの変動の有無を制御部１１２に通知する。データ受信状態検出部１１１は、ログ情報を取得する取得手段の一例である。【００４４】
制御部１１２は、データ受信状態検出部１１１からのデータ受信の有無および受信データの変動の有無（受信状態信号）を通知される。また、制御部１１２は、チップセット３からのリセット信号を受け付ける。そして、制御部１１２は、タイマ１１３によって、受信状態信号とリセットとの関係を判定し、バッファ１３−０、１３−１の切替タイミングを決定する。制御部１１２は、リセットを検出する手段およびログ情報を取得する取得手段の一例である。【００４５】
すなわち、制御部１１２は、受信状態信号により、（ａ）の発生、すなわち、第１所定時間Ｔ１の間、データの受信がない、もしくは受信データの変動がない場合に、タイマ１１３を起動する。第１所定時間Ｔ１が、ログ情報が出力されない期間の一例である。ここで、ログ情報が出力されないとは、例えば、受信データ量が０、すなわち、受信データなしの場合でもよい。また、ログ情報が出力されないとは、受信データが規定値以下の場合であってもよい。また、ログ情報が出力されないとは、受信データの変動がない場合であってもよい。また、ログ情報が出力されないとは、受信データの変動が規定値以下の場合であってもよい。受信データの変動が規定値以下とは、例えば、短時間あたりの変動ビット数が規定値以下として定義できる。【００４６】
そして、（ａ）の発生から第２所定時間Ｔ２以内に（ｂ）、サーバ再起動時に発生するリセット信号を検知した場合に、制御部１１２は切替トリガを切替スイッチ１２に供給する。切替トリガは、切替スイッチ１２の接続先と同期したレジスタビットを反転させる。その結果、切替スイッチ１２は、切替トリガに応じて、コンソールデータ受信部１１とバッファ１３−０、または、コンソールデータ受信部１１とバッファ１３−１を接続する。【００４７】
ただし、第１所定時間Ｔ１の経過後、さらに、第２所定時間Ｔ２が経過した場合には、再度（ａ）（ｂ）の処理が繰り返される。また、これらの処理の途中で、コンソールログが受信された場合には、（ａ）（ｂ）の処理は停止され、通常状態に戻る。【００４８】
以上の構成によって、第１所定時間Ｔ１の間、チップセット３からデータ受信がない、またはデータの変動がないことが確認された後、第２所定時間Ｔ２以内にリセット信号が入力されると、制御部１１２は、切替スイッチ１２を切り替える。例えば、切替スイッチ１２は、コンソールデータ受信部１１の接続先をバッファ１３−０からバッファ１３−１に切り替える。以上の切替によって、異常発生前後のコンソールログを保存できる。【００４９】
図５に、サーバ停止処理実行時の処理フローを例示する。図５の処理は、例えば、ユーザによるシャットダウンコマンドの入力で開始する。シャットダウンコマンドの入力により、各種コンピュータプログラムが停止する（Ｓ１０）。【００５０】
次に、周辺機器等の各種ハードウェアモジュール、およびハードウェアモジュールを駆動するドライバ等が停止する（Ｓ１１）。なお、Ｓ１１の処理の途中で、ＯＳによるシステムログの取得、および保存が停止する。さらに、ＷＤＴ２も停止する。次にＯＳが停止する（Ｓ１２）。この処理では、シャットダウンコマンドの入力以降、所定時間あるいは所定量のコンソールログが取得され、ＯＳが停止する。【００５１】
ただし、Ｓ１１の処理で、ＯＳのシステムログが保存されなくなった後に、情報処理装置９に異常が発生した場合が問題となる。この場合には、ＯＳの停止前に、コンソールログの受信が途絶える。そこで、ユーザは、例えば、外部スイッチ等により情報処理装置９をリセットする（Ｓ１３）。あるいは、情報処理装置９の例外処理等によって、情報処理装置９にリセットが指令される。その結果、情報処理装置９がリセットされ、再起動の後、再度シャットダウンコマンドの実行により、情報処理装置９が停止する。【００５２】
異常発生前、バッファ１３−０には、シャットダウン時のコンソールログが異常発生まで蓄積されている。そして、異常発生によって、コンソールログの受信が停止する。さらに、上記、コンソールログを受信することなく、リセット信号を受信すると、情報処理装置９が再起動し、起動時のコンソールログが出力される。【００５３】
図６は、サーバ起動時の処理フローを例示する。図６の処理は、例えば、ユーザによるサーバ起動操作で開始する。サーバ起動操作により、まず、ＢＩＯＳがロードされる（Ｓ２０）。次に、Power On Self Test（ＰＯＳＴ）が開始し、完了する（Ｓ２１）。次に、Master Boot Record(ＭＢＲ)がロードされ、さらに、Boot Loaderが起動される（Ｓ２２）。次に、ＯＳが起動開始する（Ｓ２３）。【００５４】
次に、周辺機器等の各種ハードウェアモジュール、およびハードウェアモジュールを駆動するドライバ等が起動を開始する（Ｓ２４）。なお、Ｓ２４の処理の途中で、ＯＳによるシステムログの取得、および保存が開始する。さらに、ＷＤＴ２が起動される。次に、各種コンピュータプログラムの起動が開始する（Ｓ２５）。ここで、Ｓ２４以降は、ＯＳがシステムログを記録する。したがって、Ｓ２４の処理以降に異常が発生しても、異常発生の状況はシステムログに記録可能性がある。一方、Ｓ２０からＳ２４の間は、コンソールログが出力される。【００５５】
実施例１の処理は、Ｓ２０からＳ２４の間で異常が発生したときに、異常発生時のコンソールログを保存することを可能とする。そのため、情報処理装置９は、以下の処理を実行する。
（Ａ）情報処理装置９起動時のリセット後、第３所定時間Ｔ３に達するか否かを判定する。
（Ｂ）リセット後、第３所定時間Ｔ３に達する前に、データ受信の有無および受信データの変動の有無を検知する。そして、データ受信の有無および受信データの変動が第１所定時間Ｔ１の間継続すると、制御部１１２は、切替スイッチ１２を切り替える。例えば、切替スイッチ１２は、コンソールデータ受信部１１の接続先をバッファ１３−０からバッファ１３−１に切り替える。その結果、図６において、Ｓ２０からＳ２４の間で、コンソールログが第１所定時間Ｔ１以上受信できない場合に、コンソールログが受信できなくなる前に受信済みのコンソールログを切替スイッチ１２による切替前のバッファ１３−０に保存できる。【００５６】
また、制御部１１２はＷＤＴ２からのプレタイムアウト信号を受信すると、切替トリガを切替スイッチ１２に供給する。この場合には、ＷＤＴ２によるプレタイムアウト信号受信前のコンソールログが、一方のバッファ、例えば、バッファ１３−０に保存され、ＷＤＴ２によるプレタイムアウト信号受信後のコンソールログが、他方のバッファ、例えば、バッファ１３−１に保存される。【００５７】
図７は、ＷＤＴ２によるプログラムの異常発生を検知する処理フローを例示する図である。情報処理装置９で実行中のプログラムに異常が発生し、情報処理装置９がフリーズすると、ＷＤＴ２によるプレタイムアウトが発生する（Ｓ３０）。この間、例えば、コンソールログは、バッファ１３−０に蓄積される。そして、ＷＤＴ２によるプレタイムアウトがＯＳに通知される。ＯＳは、クラッシュダンプをコンソールログに出力する（Ｓ３１）。なお、クラッシュダンプは、ＯＳのシステムログにも記録される。その後、情報処理装置９は、ユーザ操作、あるいは、情報処理装置９の例外処理等によってリセットされ（Ｓ３２）、再起動される。【００５８】
実施例１の処理では、ＷＤＴ２のプレタイムアウトによって、切替スイッチ１２は、コンソールデータ受信部１１の接続先をバッファ１３−０からバッファ１３−１に切り替える。以上の切替によって、異常発生前後のコンソールログをバッファ１３−０に保存できる。【００５９】
図８に、通常稼働のシーケンスとシャットダウン時に異常が発生した場合のシーケンスとを比較して例示する。図８で、縦軸は、時間軸に相当する。また、図８の横軸方向には、情報処理装置９の構成要素、すなわち、バッファ１３−０、１３−１、切替スイッチ１２、ＷＤＴ２、ＩＰＭＣ１のコンソールデータ受信部１１、およびチップセット３のＣＰＵで実行されるＯＳとアプリケーションプログラムが例示されている。また、図８は、上下２つに分割されたシーケンスとなっている。【００６０】
図８の上側のシーケンスは、通常時、例えば、情報処理装置９の稼働中のシーケンスを示している。通常の稼働状態では、ＯＳあるいはアプリケーションからコンソールログが出力され、コンソールデータ受信部１１および切替スイッチ１２を介して、バッファ１３−０に出力される（矢印Ａ１）。また、ＯＳからＷＤＴ２に対して、タイマ初期化信号が送信される（矢印Ａ２）。【００６１】
そして、例えば、コンソールデータ受信部１１の制御部１１２がデータ受信なしあるいは受信データの変動なしを検知すると、タイマにより時間ｔ１の計時を開始する。そして、時間ｔ１が、第１所定期間Ｔ１を超えると、制御部１１２は、データ受信なしあるいは受信データの変動なしの状態であるとの判断を確定する。データ受信なしあるいは受信データの変動なしの状態であるとの判断を確定することを不通状態の確定という。ただし、図８では、タイマ１１３の計時する時間ｔ１が、第１所定時間Ｔ１経過後、第２所定時間Ｔ２経過前に、情報処理装置９のリセットは発生しない。第２所定時間Ｔ２経過前に、情報処理装置９のリセットが発生しない場合、制御部１１２は、タイマ１１３を再設定し、時間ｔ１の計時を時刻０から再開する。そして、制御部１１２は、再度、所定時間Ｔ１の経過による不通状態の確定と、第２所定時間Ｔ２経過前のリセットの発生を監視する。【００６２】
そして、図８の上側のシーケンスでは、第２所定時間Ｔ２経過後、不通状態が解除となり、データ送信が再開されている。その結果、制御部１１２は、データ受信を再開し（矢印Ａ３）、情報処理装置９は、通常の稼働状態に戻っている。【００６３】
図８の下側のシーケンスは、シャットダウン時にエラーが発生した場合のシーケンスを示している。図８の下側のシーケンスでは、シャットダウンの指示、例えば、シャットダウンコマンドの投入により、ＯＳからコンソールログが出力され、コンソールデータ受信部１１および切替スイッチ１２を介して、バッファ１３−０に記録される（矢印Ａ４）。ここでは、シャットダウンの実行中に、情報処理装置９の異常により、情報処理装置９がフリーズし、データ送信が停止された場合を想定する。データ送信が停止すると、タイマ１１３が起動され、時間ｔ１が第１所定時間Ｔ１を超えると、制御部１１２は不通状態を確定する。すると、制御部１１２は、さらに、タイマ１１３を初期化し、時間ｔ２を計時する。【００６４】
そして、時間ｔ２が第２所定時間Ｔ２経過前に、リセットが発生すると（矢印Ａ５）、制御部１１２は、切替スイッチ１２を切り替える。すると、切替スイッチ１２は、コンソールデータ受信部１１の接続先をバッファ１３−０からバッファ１３−１に切り替える。すなわち、制御部１１２は、切替スイッチ１２のレジスタビットを０から１に変更する。その結果、図８の下側のシーケンスにおいて、シャットダウン中のフリーズが発生する直前のコンソールログをバッファ１３−０に維持できる。また、情報処理装置９がリセットされた後、復旧処理後のコンソールログは、バッファ１３−１に出力される（矢印Ａ６）。【００６５】
なお、再度時間ｔ１の計時が開始された後、第１所定時間Ｔ１経過前に、リセットが発生すると、制御部１１２が切替スイッチ１２を切り替えることなく、情報処理装置９は、起動時の状態に移行する可能性がある。しかしながら、第１所定時間Ｔ１を第２所定時間Ｔ２に比べて十分に短くすることで、不通状態の確定と、第２所定時間Ｔ２経過前のリセットの発生検出によるバッファ１３−０、１３−１の切替を実行できる可能性を高めることができる。【００６６】
図９は、情報処理装置９の起動によるリセット後のシーケンスを例示する。図９の上側は、情報処理装置９での異常のない通常状態でのシーケンスを例示する。すなわち、情報処理装置９のリセット後、ＯＳあるいはアプリケーションからコンソールログが出力され、コンソールデータ受信部１１および切替スイッチ１２を介して、バッファ１３−０に出力される（矢印Ａ７）。また、さらに、ＷＤＴ２が起動され、ＯＳからＷＤＴ２に対して、タイマ初期化信号の送信が開始される（矢印Ａ８）。そして、ＯＳあるいはアプリケーションからコンソールログは、例えば、第３所定時間Ｔ３を経過したところで、停止する（矢印Ａ９）。コンソールログが停止するのは、情報処理装置９のリセット後、所定の起動処理は、第３所定時間Ｔ３程度で完了するからである。第３所定時間Ｔ３以降、情報処理装置９は、通常の稼働状態となり、例えば、ユーザからの指示を待つ。【００６７】
一方、図９の下側は、情報処理装置９の起動時に、異常が発生したシーケンスを例示する。図９の下側のシーケンスでは、情報処理装置９のリセット後、第３所定時間Ｔ３経過前に、コンソールログのデータ送信が停止する（矢印Ａ１０）。矢印Ａ１０は、データ送信停止直前のコンソールログの送信を例示している。【００６８】
コンソールログのデータ送信が停止すると、データ受信状態検出部１１１は、制御部１１２に、コンソールログのデータ受信停止を通知する。すると、制御部１１２は、タイマ１１３により時間ｔ１の計時を開始する。そして、コンソールログのデータ受信停止期間、すなわち、時間ｔ１が第１所定時間Ｔ１を経過すると、制御部１１２は、不通状態が確定したと判定する。そこで、制御部１１２は、切替スイッチ１２を切り替える。すると、切替スイッチ１２は、コンソールデータ受信部１１の接続先をバッファ１３−０からバッファ１３−１に切り替える。すなわち、制御部１１２は、切替スイッチ１２のレジスタビットを０から１に変更する。その後、情報処理装置９の例外処理、あるいは、ユーザ動作によって、情報処理装置９がリセットされる。リセットによる復旧処理後のコンソールログは、バッファ１３−１に出力される（矢印Ａ１１）。【００６９】
図１０に、ＷＤＴ２がＯＳまたはアプリケーションのフリーズ状態を検出した場合のシーケンスを例示する。ＯＳまたは情報処理装置９で実行中のアプリケーションがフリーズすると、図３で説明したように、例えば、ＷＤＴ２のプレタイムアウトが発生する。ＷＤＴ２は、プレタイムアウトの発生を制御部１１２に通知する。すると、制御部１１２は、切替スイッチ１２のレジスタビットを０から１に変更する。その結果、切替スイッチ１２は、コンソールデータ受信部１１の接続先をバッファ１３−０からバッファ１３−１に切り替える。【００７０】
一方、プレタイムアウトによって、ＷＤＴ２は、ＯＳに割り込みをかける。すると、ＯＳは、クラッシュダンプを出力し、情報処理装置９をリセットする。したがって、クラッシュダンプおよび情報処理装置９のリセットによる復旧後のコンソールログは、バッファ１３−１に出力される。その結果、ＯＳあるいはアプリケーションがフリーズ直前のコンソールログは、バッファ１３−０に保持される。ただし、ＯＳが障害によって情報処理装置９をリセットすることができない場合には、ＷＤＴ２は、プレタイムアウトからさらに進行し、タイムアウトを発生する。ＷＤＴ２はタイムアウトを発生すると、ＯＳに代わって、情報処理装置９をリセットする。ＷＤＴ２によるリセットの結果、情報処理装置９は、再起動され、復旧処理を開始する。【００７１】
＜処理フロー＞
図１１および図１２に、ＩＰＭＣ１の制御部１１２の処理フローを例示する。また、ＩＰＭＣ１のＣＰＵは、ＲＯＭ上のファームウェア、コンピュータプログラム等を主記憶装置にローディングし、制御部１１２として機能する。なお、図１１で、「開始」以降の処理は、情報処理装置９の起動が完了し、通常動作している状態を例示する。【００７２】
情報処理装置９の通常動作状態で制御部１１２は、ＷＤＴ２からのプレタイムアウトを確認する（Ｓ１０１）。そして、ＷＤＴ２からのプレタイムアウトの通知があった場合、制御部１１２は、図１２のＳ１１８に制御を進める。制御部１１２は、契機信号にしたがってログ情報の格納先を切り替える手段として、Ｓ１０１、Ｓ１１８の処理を実行する。【００７３】
ただし、ＷＤＴ２は、プレタイムアウトを制御部１１２に割り込みで通知するようにしてもよい。割り込みによる通知の場合には、制御部１１２は、Ｓ１０１で、プロタイムアウトを確認することなく、割り込みがあった場合に図１７のＳ１１８を実行すればよい。割り込みがあった場合にとは、例えば、割り込みがあったときに起動される割り込みハンドラ等によって、制御部１１２の制御をＳ１１８に進める、という意味である。【００７４】
一方、ＷＤＴ２からのプレタイムアウトの通知がない場合、制御部１１２は、時間ｔ１計時のため、タイマ１１３を初期設定する（Ｓ１０２）。そして、制御部１１２は、リセットが発生したか否かを判定する（Ｓ１０３）。制御部１１２は、リセットを検出する手段の一例として、Ｓ１０３の処理を実行する。【００７５】
ここで、リセットとは、例えば、情報処理装置９起動時に、チップセット３のＣＰＵから発せられる初期化の指令である。リセットが発生した場合、制御部１１２は、制御をＳ１１２に進める。Ｓ１１２以降では、リセット発生時の処理、すなわち、情報処理装置９起動時の処理が実行される。【００７６】
また、Ｓ１０３の判定で、リセットが発生していない場合、制御部１１２は、チップセット３からのデータ線が不通状態か否かを判定する（Ｓ１０４）。不通状態か否かは、図４のデータ受信状態検出部１１１から制御部１１２に通知される。そして、データ線が不通状態でない場合、制御部１１２は、制御をＳ１０１に戻す。【００７７】
一方、データ線が不通状態の場合、制御部１１２は、タイマ１１３の計時時間ｔ１が第１初期値Ｔ１を経過したか否かを判定する（Ｓ１０５）。そして、タイマ１１３の計時時間ｔ１が第１初期値Ｔ１を経過していない場合、制御部１１２は、制御をＳ１０４に戻し、再度データ線の不通状態を確認する。Ｓ０４−Ｓ１０５の処理によって、第１所定時間以上不通状態が継続した場合に、制御部１１２は、不通状態を認識する。制御部１１２は、ログ情報が所定以上出力されない期間の経過を検知する手段の一例として、Ｓ１０４、Ｓ１０５の処理を実行する。【００７８】
また、Ｓ１０５の判定で、タイマ１１３の計時時間ｔ１が第１初期値Ｔ１を経過した場合、制御部１１２は、制御部１１２内の状態レジスタを不通状態に設定する（Ｓ１０６）。そして、制御部１１２は、図１２のＳ１０７に制御を進める。そして、制御部１１２は、時間ｔ１計時のため、タイマ１１３を初期設定する（Ｓ１０７）。【００７９】
次に、制御部１１２は、リセットの発生を監視する（Ｓ１０８）。制御部１１２は、リセットを検出する手段の一例として、Ｓ１０８の処理を実行する。そして、リセットが発生しない場合、制御部１１２は、データ線が不通状態か否かを判定する（Ｓ１０９）。そして、データ線が不通状態にないとき、すなわち、チップセット３からのコンソールログが受信されたとき、制御部１１２は、制御をＳ１０７に戻す。【００８０】
また、Ｓ１０９の判定で、データ線が不通状態のとき、制御部１１２は、タイマ１１３の計時する時間ｔ１が第２所定時間Ｔ２を経過したか否かを判定する。そして、時間ｔ１が第２所定時間Ｔ２を経過していない場合、制御部１１２は、制御をＳ１０８に戻し、リセットの発生を監視する。一方、時間ｔ１が第２所定時間Ｔ２を経過した場合、制御部１１２は、状態レジスタの不通状態を解除する（Ｓ１１１）。そして、制御部１１２は、制御をＳ１０１に戻す。つまり、リセットが発生せずに、時間ｔ１が第２所定時間Ｔ２を経過した場合には、制御部１１２は、Ｓ１０１からの処理を始めから繰り返す。【００８１】
また、Ｓ１０８の判定で、リセットの発生が確認された場合、制御部１１２は、切替スイッチ１２によりバッファ１３−０と１３−１の接続を切り替える（Ｓ１１８）。すなわち、コンソールデータ受信部１１の接続先をバッファ１３−０と１３−１との間で、入れ替える。制御部１１２は、ログ情報が所定以上出力される前にリセットが検出されたときに、ログ情報の格納先を切り替える手段として、Ｓ１０８、Ｓ１１８の処理を実行する。【００８２】
また、図１１のＳ１０３の判定で、リセット発生が確認された場合、情報処理装置９は、Ｓ１１２以降の情報処理装置９の起動中の処理を実行する。すなわち、制御部１１２は、時間ｔ１を計時するタイマ１１３を初期設定する（Ｓ１１２）。そして、制御部１１２は、データ線が不通状態か否かを判定する（Ｓ１１３）。そして、データ線が不通状態でない場合、制御部１１２は、制御をＳ１１２に戻す。したがって、リセット発生後、データが不通状態にならない限り、時間ｔ１の初期化が、所定の時間間隔で実行される。ただし、情報処理装置９のリセット後、所定量のコンソールログが出力された後、情報処理装置９が通常の稼働状態になると、コンソールログの出力はなくなる。【００８３】
すなわち、Ｓ１１３の判定で、データ線が不通状態になると、次に制御部１１２は、時間ｔ１が第１所定時間Ｔ１を経過したか否かを判定する（Ｓ１１４）。そして、時間ｔ１が第１所定時間Ｔ１を経過していない場合、制御部１１２は、制御をＳ１１３に戻し、データ線の不通を確認する（Ｓ１１３）。Ｓ１１３−Ｓ１１４の処理によって、第１所定時間以上不通状態が継続した場合に、制御部１１２は、不通状態を認識する。【００８４】
そして、Ｓ１１４の判定で、時間ｔ１が第１所定時間Ｔ１を経過した場合、制御部１１２は、状態レジスタを不通状態に設定する（Ｓ１１５）。次に、制御部１１２は、データ線の不通を確認する（Ｓ１１６）。そして、データ線が不通状態でない場合、制御部１１２は、制御をＳ１０７に進める。そして、制御部１１２は、Ｓ１０７以降の通常稼働中にシャットダウンが指示された場合の動作に備える。【００８５】
一方、Ｓ１１６の判定で、データ線が不通状態である場合、制御部１１２は、時間ｔ１が第３所定時間Ｔ３を経過したか否かを判定する（Ｓ１１７）。そして、時間ｔ１が第３所定時間Ｔを経過した場合、制御部１１２は、制御をＳ１１６に戻し、データ線の不通状態を確認する。時間ｔ１が第３所定時間Ｔを経過した場合には、リセット後のコンソールログの出力が完了したと考えてよい。したがって、制御部１１２は、再度データ線の不通状態を確認するのである。【００８６】
また、Ｓ１１７の判定で、時間ｔ１が第３所定時間Ｔを経過していない場合、制御部１１２は、制御をＳ１１８に進め、バッファを切り替える。Ｓ１１７の判定で、時間ｔ１が第３所定時間Ｔを経過していない場合には、リセット発生後、本来出力されるコンソールログが出力される前に、データ線が不通状態となり、不通状態の継続期間が第１所定時間Ｔ１に達したと判定されたからである。制御部１１２は、リセット検出後の所定期間経過前に、ログ情報が所定以上出力されないときにログ情報の格納先を切り替える手段として、Ｓ１１７、Ｓ１１８の処理を実行する。【００８７】
以上述べたように、実施例１の情報処理装置９によれば、制御部１１２は、第１所定時間Ｔ１以上、データ線を通じたチップセット３からＩＰＭＣ１のデータポートへのコンソールログの不通状態が継続することを確認する。そして、不通状態確認後、制御部１１２は、情報処理装置９でのリセット発生を監視し、リセットが発生すると、切替スイッチ１２によって、コンソールデータ受信部１１の出力先を、例えば、バッファ１３−０からバッファ１３−１に切り替える。したがって、不通状態となる前にバッファ１３−０に出力されていたコンソールログをバッファ１３−０に保持する一方、リセット後のコンソールログをバッファ１３−１に蓄積できる。このような処理によって、不通状態になった後に、情報処理装置９の例外処理、あるいは、ユーザの動作によって、情報処理装置９がリセットし、復旧処理が実施される場合でも、不通状態になる前のコンソールログ、つまり、障害発生時のコンソールログを保存できる。【００８８】
さらに、制御部１１２は、不通状態確認後のリセットの監視を第２所定時間Ｔ２まで継続し、第２所定時間経過後は、再度不通状態が第１所定時間Ｔ１継続するか否かを確認する。したがって、情報処理装置９が通常稼働中に、コンソールログが第１所定時間Ｔ１以上継続し、その後、コンソールログが出力された場合には、バッファ１３−０とバッファ１３−１の切替を抑制できる。バッファ切替を抑制する理由は、正常な通常処理でのコンソールログを複数のバッファを切り替えて保存しなくてもよいからである。すなわち、情報処理装置９によれば、本来取得したい障害発生時のログと、その障害発生時以降の復旧処理でのログを効果的に分離して格納できる。【００８９】
また、情報処理装置９によれば、情報処理装置９の起動後、第３所定時間Ｔ３の経過前に、第１所定時間Ｔ１以上、コンソールログの不通状態が継続する否かを確認する。そして、第１所定時間Ｔ１以上、コンソールログの不通状態が継続すると、制御部１１２は、不通状態を確認する。そして、不通状態確認後、制御部１１２は、切替スイッチ１２によって、コンソールデータ受信部１１の出力先を、例えば、バッファ１３−０からバッファ１３−１に切り替える。【００９０】
このようなバッファ１３−０からバッファ１３−１への切り替えによって、情報処理装置９の起動に伴うリセット時の不通状態からの復旧処理、例えば、リセットが行われた場合でも、起動後の障害発生時のコンソールログを例えば、バッファ１３−０に保存し、復旧処理に伴うコンソールログをバッファ１３−１に出力できる。したがって、情報処理装置９は、不通状態となる前にバッファ１３−０に出力されていたコンソールログをそのまま保持にできる。【００９１】
また、第３所定時間Ｔ３の経過後に、制御部１１２は、通常稼働時のコンソールログの不通状態を確認する処理に移行する。第３所定時間Ｔ３の経過後は、情報処理装置９の起動によるリセット時のコンソールログが正常に出力されたと考えることができるからである。【００９２】
ただし、第３所定時間Ｔ３の経過の有無に関わらず、不通状態を確認するようにしてもよい。この場合には、シャットダウン時の不通状態の監視処理と、起動時の不通状態監視処理を同一の処理で実行できる。【００９３】
さらに、情報処理装置９によれば、制御部１１２は、ＷＤＴ２によって、ＯＳあるいはアプリケーションプログラムによる情報処理装置９のフリーズ、あるいは、コンソールログの不通を監視する。そして、ＷＤＴ２からの通知があると、制御部１１２は、切替スイッチ１２によって、コンソールデータ受信部１１の出力先を、例えば、バッファ１３−０からバッファ１３−１に切り替える。したがって、情報処理装置９によれば、不通状態からの復旧処理、例えば、情報処理装置９のリセットに伴うコンソールログがバッファ１３−１に出力されるので、不通状態となる前にバッファ１３−０に出力されていたコンソールログをそのまま保持にできる。
【実施例２】
【００９４】
図１３−図１６を参照して、実施例２に係る情報処理装置９を説明する。実施例１では、チップセット３からＩＰＭＣ１のデータポートへのデータ線を通じたコンソールログの不通状態等をタイマ１１３、ＷＤＴ２等の計時により確認した。実施例２では、時間の代わりに、チップセット３からＩＰＭＣ１のデータポートへのデータ線を通じたコンソールログのデータ量、例えば、単位時間あたりのデータ転送量によって、不通状態等を確認する。コンソールログのデータ量によって、不通状態等を確認する点以外の処理については、第２実施形態の構成要素は、第１実施形態の構成要素と同様である。そこで、第１実施形態と同一の構成要素については、同一の符号を付して説明を省略する。例えば、情報処理装置９の構成は、図１と同様であるので、その説明は省略する。ただし、実施例２では、情報処理装置９は、ＩＰＭＣ１に代えて、ＩＰＭＣ１Ａを有する。【００９５】
図１３に、実施例２に係るＩＰＭＣ１Ａの構成を例示する。図１３のように、ＩＰＭＣ１Ａは、コンソールログ受信部１１に代えて、コンソールログ受信部１１Ａを有する点が、実施例１の図２と相違する。【００９６】
図１４に、実施例に係るコンソールデータ受信部１１Ａの構成を例示する。図１４のように、コンソールデータ受信部１１Ａは、制御部１１２およびタイマ１１３に代えて、制御部１１２Ａおよびカウンタ１１３Ａを有する点が実施例１のコンソールデータ受信部１１と相違する。すなわち、コンソールデータ受信部１１Ａは、タイマ１１３で計時する代わりに、カウンタ１１３Ａによって、データ線を通じたチップセット３からデータポートへの受信データ量を監視することで、不通状態等の確認と解除を行う。【００９７】
図１５に、通常稼働のシーケンスとシャットダウン時に異常が発生した場合のシーケンスとを比較して例示する。図１５においても、実施例１の図８と同様に、ＯＳあるいはアプリケーションからコンソールログが出力され、コンソールデータ受信部１１および切替スイッチ１２を介して、バッファ１３−０に出力される（矢印Ａ１）。また、ＯＳからＷＤＴ２に対して、タイマ初期化信号が送信される（矢印Ａ２）。【００９８】
ただし、実施例２では、例えば、コンソールデータ受信部１１の制御部１１２がデータ受信なしあるいは受信データの変動なしを検知すると、制御部１１２は、カウンタ１１３Ａをクリアする。そして、制御部１１２は、カウンタ１１３Ａのクリア後、コンソールログの受信バイト数をカウントする。そして、受信バイト数が、第１基準バイト数Ｃ１未満の受信バイト数であるか否かを判定する。制御部１１２は、カウンタ１１３Ａクリア後の受信バイト数が、Ｃ１バイト未満のとき、チップセット３からのデータ線を通じたコンソールログの不通状態が継続していると判定する。【００９９】
その後、受信バイト数が増加し、受信バイト数がＣ２バイトに達した場合には、制御部１１２は、バッファ１３−０と１３−１との切替を実行しない。通常の稼働状態であると判断できるからである。すなわち、図１５の上側のシーケンスでは、Ｃ２バイト以上を受信後、不通状態が解除となり、データ送信が再開されている。その結果、制御部１１２は、データ受信を再開し（矢印Ａ３）、情報処理装置９は、通常の稼働状態に戻っている。【０１００】
図１５の下側のシーケンスは、シャットダウン時にエラーが発生した場合のシーケンスを示している。図１５の下側のシーケンスでは、シャットダウンの指示、例えば、シャットダウンコマンドの投入により、ＯＳからコンソールログが出力され、コンソールデータ受信部１１および切替スイッチ１２を介して、バッファ１３−０に出力される（矢印Ａ４）。そして、実施例１の図８と同様、シャットダウンの実行中に、情報処理装置９の異常により、情報処理装置９がフリーズし、データ送信が停止された場合を想定する。すると、制御部１１２は、カウンタ１１３Ａをクリアし、受信バイト数が第１基準バイト数Ｃ１未満であるか否かを判定する。【０１０１】
そして、受信バイト数が第２基準バイト数Ｃ２に達するまで、制御部１１２は、リセットの発生を監視する。
そして、受信バイト数が第２基準バイト数Ｃ２に達する前に、リセットが発生すると（矢印Ａ５）、制御部１１２は、切替スイッチ１２を切り替える。すると、切替スイッチ１２は、コンソールデータ受信部１１の接続先をバッファ１３−０からバッファ１３−１に切り替える。すなわち、制御部１１２は、切替スイッチ１２のレジスタビットを０から１に変更する。その結果、図１５の下側のシーケンスにおいて、シャットダウン中のフリーズが発生する直前のコンソールログをバッファ１３−０に維持できる。また、情報処理装置９がリセットされた後、復旧処理後のコンソールログは、バッファ１３−１に出力される（矢印Ａ６）。【０１０２】
以上の説明では、不通状態をカウンタ１１３Ａクリア後の受信バイト数が、第１基準バイト数Ｃ１未満の間と定義し、リセット発生の監視を受信バイト数が第２基準バイト数Ｃ２に達するまで行うとした。このようなバイト数に判断を短時間あたりの受信バイト数で行ってもよい。すなわち、制御部１１２がデータ受信なしあるいは受信データの変動なしを検知すると、単位時間あたりの受信バイト数が、第１基準バイト数Ｃ１未満であるか否かを判定し、不通状態の継続を確認してもよい。また、制御部１１２は、不通状態の継続を確認後、単位時間あたりの受信バイト数が、第２基準バイト数Ｃ２に達するまで、リセットの発生を監視してもよい。そして、一旦、単位時間あたりの受信バイト数が、第２基準バイト数Ｃ２に達した場合には、再度、データ受信なしあるいは受信データの変動なしを検知するようにしてもよい。逆に、単位時間あたりの受信バイト数が、第２基準バイト数Ｃ２に達しない場合に、リセット発生の監視を継続してもよい。【０１０３】
以上述べたように、受信バイト数の確認によって、実施例１と同様、あるいは、実施例１よりもさらに厳密に、不通状態の継続判定ができる。その結果、不通状態となる直前のコンソールログを例えば、バッファ１３−０に保存し、不通状態でリセットが発生し、復旧後のコンソールログをバッファ１３−１に出力できる。【０１０４】
図１６に、通常稼働のシーケンスと起動時に異常が発生した場合のシーケンスとを比較して例示する。図１６の上側のシーケンスでも、実施例１の図９と同様に、情報処理装置９のリセット後、ＯＳあるいはアプリケーションからコンソールログが出力され、コンソールデータ受信部１１および切替スイッチ１２を介して、バッファ１３−０に出力される（矢印Ａ７）。また、さらに、ＷＤＴ２が起動され、ＯＳからＷＤＴ２に対して、タイマ初期化信号の送信が開始される（矢印Ａ８）。そして、ＯＳあるいはアプリケーションからコンソールログは、例えば、第３所定基準バイト数Ｃ３以上受信した場合には、制御部１１２は、情報処理装置９が正常に起動されたと判定する。そのため、制御部１１２は、バッファ１３−０とバッファ１３−１の切替を実行しない。【０１０５】
一方、図９の下側は、情報処理装置９の起動時に、異常が発生したシーケンスを例示する。図９の下側のシーケンスでは、情報処理装置９のリセット後、第３基準バイト数Ｃ３の受信前に、コンソールログのデータ送信が停止する（矢印Ａ９）。矢印Ａ９は、データ送信停止直前のコンソールログの送信を例示している。【０１０６】
すなわち、制御部１１２がデータ受信のなしあるいは受信データの変動のなしを検知すると、制御部１１２は、カウンタ１１３Ａをクリアする。そして、制御部１１２は、カウンタ１１３Ａクリア後の受信バイト数が、第１基準バイト数Ｃ１未満の受信バイト数であるか否かを判定する。制御部１１２は、カウンタ１１３Ａクリア後の受信バイト数がＣ１バイト未満のとき、チップセット３からのデータ線を通じたコンソールログの不通状態が確定したと判定する。【０１０７】
そこで、制御部１１２は、切替スイッチ１２を切り替える。すると、切替スイッチ１２は、コンソールデータ受信部１１の接続先をバッファ１３−０からバッファ１３−１に切り替える。すなわち、制御部１１２は、切替スイッチ１２のレジスタビットを０から１に変更する。その後、情報処理装置９の例外処理、あるいは、ユーザ動作によって、情報処理装置９がリセットされる。リセットによる復旧処理後のコンソールログは、バッファ１３−１に出力される（矢印Ａ１０）。【０１０８】
以上述べたように、受信バイト数のカウント１１３Ａによって、実施例１と同様、あるいは、実施例１よりも厳密に、コンソールログの不通状態を検知できる。したがって、情報処理装置９の起動時の異常を検知し、不通状態となる直前のコンソールログを、例えばバッファ１３−０に保存し、不通状態でのリセット時、および異常からの復旧後のコンソールログをバッファ１３−１に出力できる。【０１０９】
なお、図１６の処理でも、第１基準バイト数Ｃ１あるいは第３基準バイト数の判断を単位時間あたりの受信バイトと比較して、不通状態の継続、あるいは、起動処理の正常終了等を判定してもよい。【０１１０】
＜コンピュータが読み取り可能な記録媒体＞
ＩＰＭＣ１で例示されるコンピュータその他の機械、装置（以下、コンピュータ等）に上記いずれかの機能を実現させるプログラムをコンピュータ等が読み取り可能な記録媒体に記録することができる。そして、コンピュータ等に、この記録媒体のプログラムを読み込ませて実行させることにより、その機能を提供させることができる。【０１１１】
ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。このような記録媒体のうちコンピュータ等から取り外し可能なものとしては、例えばフレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／Ｗ、ＤＶＤ、ブルーレイディスク、ＤＡＴ、８ｍｍテープ、フラッシュメモリなどのメモリカード等がある。また、コンピュータ等に固定された記録媒体としてハードディスクやＲＯＭ（リードオンリーメモリ）等がある。
【符号の説明】
【０１１２】
１    ＩＰＭＣ
２    ＷＤＴ
３    チップセット
４    I/Oチップ
９    情報処理装置
１１    コンソールデータ受信部
１２    切替スイッチ
１３−０、１３−１  バッファ
１４    ログ読み出しコマンド受信部
１１１    データ受信状態検出部
１１２    制御部
１１３    タイマ
【図１】
2013008281.tif 000003
【図２】
2013008281.tif 000004
【図３】
2013008281.tif 000005
【図４】
2013008281.tif 000006
【図５】
2013008281.tif 000007
【図６】
2013008281.tif 000008
【図７】
2013008281.tif 000009
【図８】
2013008281.tif 000010
【図９】
2013008281.tif 000011
【図１０】
2013008281.tif 000012
【図１１】
2013008281.tif 000013
【図１２】
2013008281.tif 000014
【図１３】
2013008281.tif 000015
【図１４】
2013008281.tif 000016
【図１５】
2013008281.tif 000017
【図１６】
2013008281.tif 000018
【手続補正書】
【提出日】平成26年2月14日(2014.2.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
情報処理部と、
前記情報処理部がリセットされたことを検出する手段と、
前記情報処理部のログ情報を取得する取得手段と、
前記取得手段が取得したログ情報を格納する複数のバッファと、
前記リセットの検出時点と前記ログ情報の取得量との関係が所定の条件を満たすときに、前記取得手段が取得したログ情報の格納先となるバッファを切り替える制御部と、を備える情報処理装置。
【請求項２】
前記制御部は、前記ログ情報が出力されない期間が所定時間経過したか否かを検知する手段と、
前記ログ情報が出力されない期間が所定時間経過した場合、ログ情報が出力される前に前記リセットが検出されたときに、前記ログ情報の格納先を切り替える手段と、を有する請求項１に記載の情報処理装置。
【請求項３】
前記制御部は、前記リセット検出後から所定の期間の経過前に前記ログ情報が所定以上出力されないときに前記ログ情報の格納先を切り替える手段を有する請求項１または２に記載の情報処理装置。
【請求項４】
前記情報処理部からのタイマ初期化信号を所定周期で受信するとともに、前記所定周期内に前記タイマ初期化信号を受信できないときに前記所定周期の時間が経過したことを示す契機信号を発生する契機信号発生部をさらに備え、
前記制御部は、前記契機信号にしたがって前記ログ情報の格納先を切り替える手段を有する請求項１から３のいずれか１項に記載の情報処理装置。
【請求項５】
コンピュータが、
情報処理部がリセットされたことを検出するステップと、
前記情報処理部のログ情報を取得する取得ステップと、
前記取得したログ情報を複数のバッファのいずれかに格納するステップと、
前記リセットの検出時点と前記ログ情報の取得量との関係が所定の条件を満たすときに、取得したログ情報の格納先となるバッファを切り替える制御ステップと、を実行する情
報処理方法。
【請求項６】
コンピュータに、
情報処理部がリセットされたことを検出するステップと、
前記情報処理部のログ情報を取得する取得ステップと、
前記取得したログ情報を複数のバッファのいずれかに格納するステップと、
前記リセットの検出時点と前記ログ情報の取得量との関係が所定の条件を満たすときに、取得したログ情報の格納先となるバッファを切り替える制御ステップと、を実行させるためのプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００７３
【補正方法】変更
【補正の内容】
【００７３】
ただし、ＷＤＴ２は、プレタイムアウトを制御部１１２に割り込みで通知するようにしてもよい。割り込みによる通知の場合には、制御部１１２は、Ｓ１０１で、プレタイムアウトを確認することなく、割り込みがあった場合に図１２のＳ１１８を実行すればよい。割り込みがあった場合にとは、例えば、割り込みがあったときに起動される割り込みハンドラ等によって、制御部１１２の制御をＳ１１８に進める、という意味である。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００８５
【補正方法】変更
【補正の内容】
【００８５】
一方、Ｓ１１６の判定で、データ線が不通状態である場合、制御部１１２は、時間ｔ１が第３所定時間Ｔ３を経過したか否かを判定する（Ｓ１１７）。そして、時間ｔ１が第３所定時間Ｔ３を経過した場合、制御部１１２は、制御をＳ１０４に戻し、データ線の不通状態を確認する。時間ｔ１が第３所定時間Ｔを経過した場合には、リセット後のコンソールログの出力が完了したと考えてよい。したがって、制御部１１２は、通常の運用状態でデータ線の不通状態を確認するのである。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００９５
【補正方法】変更
【補正の内容】
【００９５】
図１３に、実施例２に係るＩＰＭＣ１Ａの構成を例示する。図１３のように、ＩＰＭＣ１Ａは、コンソールデータ受信部１１に代えて、コンソールデータ受信部１１Ａを有する点が、実施例１の図２と相違する。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００９７
【補正方法】変更
【補正の内容】
【００９７】
図１５に、通常稼働のシーケンスとシャットダウン時に異常が発生した場合のシーケンスとを比較して例示する。図１５においても、実施例１の図８と同様に、ＯＳあるいはアプリケーションからコンソールログが出力され、コンソールデータ受信部１１Ａおよび切替スイッチ１２を介して、バッファ１３−０に出力される（矢印Ａ１）。また、ＯＳからＷＤＴ２に対して、タイマ初期化信号が送信される（矢印Ａ２）。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００９８
【補正方法】変更
【補正の内容】
【００９８】
ただし、実施例２では、例えば、コンソールデータ受信部１１Ａの制御部１１２Ａがデータ受信なしあるいは受信データの変動なしを検知すると、制御部１１２Ａは、カウンタ１１３Ａをクリアする。そして、制御部１１２Ａは、カウンタ１１３Ａのクリア後、コンソールログの受信バイト数をカウントする。そして、受信バイト数が、第１基準バイト数Ｃ１未満の受信バイト数であるか否かを判定する。制御部１１２Ａは、カウンタ１１３Ａクリア後の受信バイト数が、Ｃ１バイト未満のとき、チップセット３からのデータ線を通じたコンソールログの不通状態が継続していると判定する。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】００９９
【補正方法】変更
【補正の内容】
【００９９】
その後、受信バイト数が増加し、受信バイト数がＣ２バイトに達した場合には、制御部１１２Ａは、バッファ１３−０と１３−１との切替を実行しない。通常の稼働状態であると判断できるからである。すなわち、図１５の上側のシーケンスでは、Ｃ２バイト以上を受信後、不通状態が解除となり、データ送信が再開されている。その結果、制御部１１２Ａは、データ受信を再開し（矢印Ａ３）、情報処理装置９は、通常の稼働状態に戻っている。
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】０１００
【補正方法】変更
【補正の内容】
【０１００】
図１５の下側のシーケンスは、シャットダウン時にエラーが発生した場合のシーケンスを示している。図１５の下側のシーケンスでは、シャットダウンの指示、例えば、シャットダウンコマンドの投入により、ＯＳからコンソールログが出力され、コンソールデータ受信部１１Ａおよび切替スイッチ１２を介して、バッファ１３−０に出力される（矢印Ａ４）。そして、実施例１の図８と同様、シャットダウンの実行中に、情報処理装置９の異常により、情報処理装置９がフリーズし、データ送信が停止された場合を想定する。すると、制御部１１２Ａは、カウンタ１１３Ａをクリアし、受信バイト数が第１基準バイト数Ｃ１未満であるか否かを判定する。
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】０１０１
【補正方法】変更
【補正の内容】
【０１０１】
そして、受信バイト数が第２基準バイト数Ｃ２に達するまで、制御部１１２は、リセットの発生を監視する。
そして、受信バイト数が第２基準バイト数Ｃ２に達する前に、リセットが発生すると（矢印Ａ５）、制御部１１２Ａは、切替スイッチ１２を切り替える。すると、切替スイッチ１２は、コンソールデータ受信部１１Ａの接続先をバッファ１３−０からバッファ１３−１に切り替える。すなわち、制御部１１２Ａは、切替スイッチ１２のレジスタビットを０から１に変更する。その結果、図１５の下側のシーケンスにおいて、シャットダウン中のフリーズが発生する直前のコンソールログをバッファ１３−０に維持できる。また、情報処理装置９がリセットされた後、復旧処理後のコンソールログは、バッファ１３−１に出力される（矢印Ａ６）。
【手続補正１０】
【補正対象書類名】明細書
【補正対象項目名】０１０２
【補正方法】変更
【補正の内容】
【０１０２】
以上の説明では、不通状態をカウンタ１１３Ａクリア後の受信バイト数が、第１基準バイト数Ｃ１未満の間と定義し、リセット発生の監視を受信バイト数が第２基準バイト数Ｃ２に達するまで行うとした。このようなバイト数に判断を短時間あたりの受信バイト数で行ってもよい。すなわち、制御部１１２Ａがデータ受信なしあるいは受信データの変動なしを検知すると、単位時間あたりの受信バイト数が、第１基準バイト数Ｃ１未満であるか否かを判定し、不通状態の継続を確認してもよい。また、制御部１１２Ａは、不通状態の継続を確認後、単位時間あたりの受信バイト数が、第２基準バイト数Ｃ２に達するまで、リセットの発生を監視してもよい。そして、一旦、単位時間あたりの受信バイト数が、第２基準バイト数Ｃ２に達した場合には、再度、データ受信なしあるいは受信データの変動なしを検知するようにしてもよい。逆に、単位時間あたりの受信バイト数が、第２基準バイト数Ｃ２に達しない場合に、リセット発生の監視を継続してもよい。
【手続補正１１】
【補正対象書類名】明細書
【補正対象項目名】０１０４
【補正方法】変更
【補正の内容】
【０１０４】
図１６に、通常稼働のシーケンスと起動時に異常が発生した場合のシーケンスとを比較して例示する。図１６の上側のシーケンスでも、実施例１の図９と同様に、情報処理装置９のリセット後、ＯＳあるいはアプリケーションからコンソールログが出力され、コンソールデータ受信部１１Ａおよび切替スイッチ１２を介して、バッファ１３−０に出力される（矢印Ａ７）。また、さらに、ＷＤＴ２が起動され、ＯＳからＷＤＴ２に対して、タイマ初期化信号の送信が開始される（矢印Ａ８）。そして、ＯＳあるいはアプリケーションからコンソールログは、例えば、第３所定基準バイト数Ｃ３以上受信した場合には、制御部１１２Ａは、情報処理装置９が正常に起動されたと判定する。そのため、制御部１１２Ａは、バッファ１３−０とバッファ１３−１の切替を実行しない。
【手続補正１２】
【補正対象書類名】明細書
【補正対象項目名】０１０６
【補正方法】変更
【補正の内容】
【０１０６】
すなわち、制御部１１２Ａがデータ受信のなしあるいは受信データの変動のなしを検知すると、制御部１１２Ａは、カウンタ１１３Ａをクリアする。そして、制御部１１２Ａは、カウンタ１１３Ａクリア後の受信バイト数が、第１基準バイト数Ｃ１未満の受信バイト数であるか否かを判定する。制御部１１２Ａは、カウンタ１１３Ａクリア後の受信バイト数がＣ１バイト未満のとき、チップセット３からのデータ線を通じたコンソールログの不通状態が確定したと判定する。
【手続補正１３】
【補正対象書類名】明細書
【補正対象項目名】０１０７
【補正方法】変更
【補正の内容】
【０１０７】
そこで、制御部１１２Ａは、切替スイッチ１２を切り替える。すると、切替スイッチ１２は、コンソールデータ受信部１１Ａの接続先をバッファ１３−０からバッファ１３−１に切り替える。すなわち、制御部１１２Ａは、切替スイッチ１２のレジスタビットを０から１に変更する。その後、情報処理装置９の例外処理、あるいは、ユーザ動作によって、情報処理装置９がリセットされる。リセットによる復旧処理後のコンソールログは、バッファ１３−１に出力される（矢印Ａ１０）。
【手続補正１４】
【補正対象書類名】図面
【補正対象項目名】図１１
【補正方法】変更
【補正の内容】
【図１１】
2013008281.tif 000019
【手続補正１５】
【補正対象書類名】図面
【補正対象項目名】図１２
【補正方法】変更
【補正の内容】
【図１２】
2013008281.tif 000020
【国際調査報告】
2013008281.tif 000021
2013008281.tif 000022