JPH096728A

JPH096728A - 端末情報収集システム

Info

Publication number: JPH096728A
Application number: JP7153690A
Authority: JP
Inventors: Takeshi Igarashi; 猛五十嵐
Original assignee: PFU Ltd
Current assignee: PFU Ltd
Priority date: 1995-06-20
Filing date: 1995-06-20
Publication date: 1997-01-10

Abstract

(57)【要約】【目的】端末装置に蓄積された情報をホスト装置で集
中管理するための端末情報収集システムに関し、ホスト
装置と端末装置との間で授受される情報量を減らして効
率の良い情報処理システムを得る。【構成】１つ又は複数の端末装置１ａないし１ｂにフ
ァイルとして蓄積された情報１４を、ホスト装置２に送
信する端末情報収集システムにおいて、一旦ホスト装置
２に対し情報を送信した以降に、各端末装置１ａないし
１ｂで蓄積された新たな情報がないか検出する未送信情
報検出手段１１を設け、新たな情報がある場合には、該
端末装置１ａないし１ｂのファイル全体を複写し、ない
場合には管理情報のみを作成して、送信情報１５とする
送信情報作成手段１２を持ち、送信手段１３でその送信
情報１５をホスト装置２へ送信する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ホスト装置と１つまた
は複数の端末装置とからなり、各端末装置に蓄積された
情報をホスト装置に収集し集中管理する情報処理システ
ムに関するもので、特に各端末装置で蓄積されたエラー
情報を、ホスト装置での解析のために収集するシステム
に関する。

【０００２】

【従来の技術】従来、端末装置の情報をホスト装置で集
中管理する必要がある場合には、端末装置に蓄積された
情報をコピーして送信情報を作成し、それをホスト装置
側に用意された領域にそのつど格納していた。そしてそ
の領域の内容を表示・印刷するソフトウェアにより、端
末装置からの情報を見るよう構成されていた。ここで、
一端コピーして送信情報を作るのは、蓄積された情報を
直接操作してミス等により削除または改変してしまうの
を防ぐためである。

【０００３】特に、その情報が各端末装置に関連して発
生したエラー情報である場合は、所定サイズのエラー・
ファイルを使うことで転送情報量の増加を防ぐという方
法をとっているものがある。エラー・ファイルは０個あ
るいは１個以上のエラー・レコードからなり、ファイル
を管理するための管理情報であるヘッダー情報域が付加
されている。ファイル・サイズを所定の大きさに保つた
めに、古いレコードから順に削除され、最新のエラー・
レコードから過去に遡り、ファイルに収まる範囲内で可
能な限り古いレコードまでが蓄積されている。

【０００４】

【発明が解決しようとする課題】しかし従来の技術で
は、情報に変化がない端末装置からも毎回必ず情報を収
集しているため、以前に送信したときのままの情報を再
度送信してしまう場合もある。このような送信済みの情
報の再送信においても、新規の情報の送信の場合と同じ
ように、ホスト装置での受信処理や通信線の占有などが
必要である。このため送信済み情報の再送信は、情報処
理システムの他の処理を圧迫し、システム全体としての
効率に影響を与えていた。

【０００５】また、１台のホスト装置に対して接続可能
な端末装置の数が増え、現状では数百台の規模となって
いる。従って、端末装置あたりの情報量が少ない場合で
も、システム全体として転送される情報量は膨大なもの
となる。この大量の情報のうち再送信であるものの出現
頻度が高い場合、さらに効率は低下する。

【０００６】従来の技術の欄で例として述べたエラー情
報の収集の場合には、エラー・レコードがホスト装置に
送られることなく消される可能性がある。それを防ぐた
めには、エラー情報の収集間隔を充分に短くして、未送
信レコードがファイル・サイズ以上に蓄積する前にホス
ト装置に送信する必要があった。ところがエラー・レコ
ードというものは本来そう頻繁にロギングされるもので
はないので、送信する内容が毎回同じである確率が高
い。これは通信線の占有率が不必要に高まることを意味
し、システム全体としての効率はさらに悪化することに
なる。

【０００７】そしてシステムの改良にあたっては、従来
の技術との互換性を高くしたいとの要望が強い。本発明
は、従来の技術との互換性を保ちながらも、ホスト装置
と端末装置との間で授受される情報量を減らし、効率の
良い端末情報収集システムを得ることを課題としてい
る。

【０００８】

【課題を解決するための手段】本発明の端末情報収集シ
ステムは、端末装置内に蓄積された情報中に未送信の情
報があるかどうかを検出する未送信情報検出手段と、未
送信の情報を検出しなかった場合には、管理情報のみを
送信情報として作成する送信情報作成手段と、送信情報
をホスト装置に送信する送信手段と、から構成される。

【０００９】さらには、送信情報の大きさが管理情報よ
り大きいかどうか判別する判別手段を送信手段に設け、
送信情報が管理情報より大きい場合のみホスト装置に送
信するように構成される。

【００１０】特に、蓄積された情報が各端末装置に関し
て発生したエラー情報である場合には、未送信情報検出
手段で所定の種別のエラー情報のみを対象として、未送
信の情報を検出するように構成される。これは、ホスト
装置で各端末装置のエラー情報を解析する際に、必要の
ないものもエラー情報の中には含まれ得るので、そのよ
うな不要な情報を除くためである。

【００１１】

【作用】図１に示した端末装置１ａないし１ｂ内に蓄積
された情報１４は、複数のレコードを含むファイルの形
で保持される。各レコードは発生した順にこのファイル
に蓄積される。蓄積された情報１４をホスト装置２に送
信するとき、これらのレコードすべてがすでにホスト装
置２に送信済みの場合は改めて送信する必要はない。

【００１２】図２に示したフローチャートは、本発明の
端末情報収集処理を従来の技術と対比するものである。
(a) は本発明のものであり、(b) が従来の技術である。
(a)の点線内の部分が、本発明により追加された処理で
ある。本発明ではまず処理３１において、蓄積された情
報１４中に未送信のレコードがあるかどうかを判断す
る。ある場合には処理３２において、少なくとも未送信
のレコードにファイルのヘッダー情報域を付加して、送
信情報１５を作成する。未送信レコードがない場合は処
理３３において、レコードなしのヘッダー情報域のみを
送信情報１５として作成する。

【００１３】このため送信情報１５のサイズは、元の蓄
積された情報１４の大きさを大きく上回ることはない。
未送信レコードがあっても同程度であるし、未送信レコ
ードがない場合には、はるかに小さくなる。なぜなら
ば、ファイルのヘッダー情報域は通常１０バイトないし
数１０バイトであり、このヘッダー情報域により数１０
キロ・バイトものファイルを管理可能だからである。

【００１４】さらに送信手段１３に判別手段を設け、送
信情報１５のサイズがヘッダー情報域より大きい場合の
み、送信情報１５をホスト装置２に送信するようにでき
る。これにより未送信レコードがない場合には、ヘッダ
ー情報域のみのファイルの送信すら省くことができる。

【００１５】そして、蓄積された情報１４が、端末装置
１ａないし１ｂに関して発生したエラー情報である場合
は、より送信データ量を削減できる。エラー情報の中に
は、ホスト装置２での解析に必要となる第１の種別のレ
コードと、必要でない第２の種別のレコードとが混在し
ているため、第１の種別のレコードのみを対象として未
送信のレコードの有無を検出すれば良いからである。

【００１６】

【実施例】図３ないし図１１を用いて、本発明の実施例
を説明する。図３は、各端末装置に蓄積されるエラー情
報を記録したエラー・ファイルの形式。図４はエラー・
ファイルに記録された各エラー・レコードの形式であ
り、レコード＃（ｎ）を例としてあげているが他のエラ
ー・レコードも同じ形式である。図５および図６は送信
用ファイルの作成について説明するためのもので、各種
レコードが蓄積されたエラー・ファイルの例および処理
のフローチャートである。図７ないし図９は送信用ファ
イルの例であり、図７はエラー・ファイル、図８は統計
情報ファイル、図９は装置名ファイルについて、各々２
つの形式を例示する。図１０は、第２の実施例を説明す
るもので、中間ファイルの作成処理のフローチャートで
ある。図１１は、第３の実施例の説明で使われる、選択
的送信処理のフローチャートである。

【００１７】図３に示すように、エラー・ファイルはヘ
ッダー情報域４とレコード格納域５とから構成され、全
体のファイル・サイズはLfバイトである。図中で左端に
示した '0000 0000'ないし '0000 000C'は、ファイル中
での位置をバイト単位の１６進数で表したものである。
すなわちこの例では、ヘッダー情報域が１２バイトあ
り、レコード格納域は位置 '0000 000C'から始まってい
る。また、この時点で最後に記録された最新のレコード
は、位置P(n)から格納されるレコード＃（ｎ）５７であ
る。

【００１８】ヘッダー情報域４には、最新レコード位置
４１と最新レコード長４２およびファイル・サイズ４３
といった情報を含んでいる。最新レコード位置４１はレ
コード＃（ｎ）５７の格納開始位置P(n)の値を持ち、最
新レコード長４２はレコード＃（ｎ）の長さL(n)バイト
である。ファイル・サイズ４３は、エラー・ファイルの
大きさであるLfバイトを示す値が入る。

【００１９】レコード格納域５には、レコード＃（１）
５１ないしレコード＃（ｎ）５７が含まれ、レコードが
格納されていない部分は空き領域５９となる。各エラー
・レコードは以下に示すような共通の形式を持つが、そ
れぞれのレコード長は可変である。

【００２０】図４に、レコード＃（ｎ）５７を例として
各レコードの形式を示す。レコードはそれぞれレコード
・ヘッダー５７１とレコード内容５７２とからなる。図
中で左端に示した '0000 0000'ないし '0000 0008'等
は、レコードの先頭バイトを０としたレコード内での相
対的な位置を表したものであり、たとえばレコード内容
５７２が位置Pxから格納されていることを示す。

【００２１】レコード・ヘッダー５７１は、前レコード
長５７３、レコード種５７４、レコード長５７５、その
他のヘッダー情報５７６からなる。前レコード長５７３
は、１つ前に記録されたレコード＃（ｎ−１）のレコー
ド長である。ここでレコード＃（ｎ）５７の格納開始位
置と前レコード長５７３とから、レコード＃（ｎ−１）
の格納開始位置が算出できる。

【００２２】レコード種５７４は、レコード＃（ｎ）５
７の種別を示す情報である。レコードの種別としては、
エラーが起こった装置のデバイス・タイプやどのような
エラーが起こったのか等、エラーそのものに関する情報
を記録した第１の種別のほかに、端末情報レコードや取
消しレコードといった第２の種別が存在する。

【００２３】端末情報レコードとは、エラー情報の収集
を行なった際に記録されるレコードで、エラー・ファイ
ルの存在する端末装置を特定するための情報を含む。エ
ラー・ファイルがどの端末装置から来たかを示すもので
あるから、以前に端末情報を収集して以来新たなエラー
が発生していなければ、これだけを送っても意味のない
レコードである。

【００２４】なお、本実施例では従来の端末情報収集シ
ステムとの混在を可能とするため、従来と共通の形式の
端末情報レコードを使用している。本発明のシステムで
は、このレコード中で未使用だった領域をフラグとして
用い、新旧どちらのシステムで収集されたかを識別す
る。

【００２５】その他、ホスト装置側では必要のない情報
として、取消しレコード等がある。取消しレコードは特
定の周辺装置に関するエラー・レコードを無効とするた
めのものである。

【００２６】取消しレコードは、特定の周辺装置を切り
離して、システム構成を変えるときに使われる。この場
合、切り離された装置に関するエラー・レコードは、そ
れ以後は必要なくなる。エラー・ファイル中に残るこの
ようなレコードを無効とするために、取消しレコードが
記録される。それ以降当該端末装置は、無効となったレ
コードが存在しないかのように振る舞い、ホスト装置に
対しても無効レコードの通知は行なわない。

【００２７】図５に、各種レコードを蓄積したエラー・
ファイルの例を示す。ファイルの先頭にはヘッダー情報
域４があり、その後にレコード＃（１）５１ないしレコ
ード＃（ｎ）５７が格納され、残りは空き領域５９であ
るとする。レコード＃（ｎ）５７は、現時点での最新レ
コードである。

【００２８】レコード＃（１）５１は、位置 '0000 000
C'から格納されている。以下同様に、レコード＃（ｎ−
４）５３、レコード＃（ｎ−３）５４、レコード＃（ｎ
−２）５５、レコード＃（ｎ−１）５６、レコード＃
（ｎ）５７の格納開始位置はそれぞれP(n-4)、P(n-3)、
P(n-2)、P(n-1)、P(n)である。このうちレコード＃（ｎ
−４）５３とレコード＃（ｎ−２）５５とは、端末情報
レコードであるとする。ただし、レコード＃（ｎ−２）
５５は旧情報収集システムにより作成されたレコードで
あるため、フラグは「ＯＦＦ」である。

【００２９】エラー・ファイルにこのようなレコードが
記録されている場合、レコード＃（ｎ−３）５４ないし
レコード＃（ｎ）５７が未送信のレコードである。ま
た、送信用ファイルの作成にあたっては、新たに今回の
端末情報レコードが付加されることになる。

【００３０】送信用ファイルの作成について、図６のフ
ローチャートを使って説明する。送信用ファイルの作成
は、各端末装置の起動時に行ない、情報収集のときには
そのファイルを送信するだけですむようにする。

【００３１】処理全体の流れとしては、最新のレコード
から１レコードずつ過去のレコードへと遡って判断して
ゆく。ここで端末情報レコード（フラグが「ＯＮ」のも
の）を発見したなら、それ以前に記録されたレコードは
送信済みであり、未送信レコードはないとして送信用フ
ァイルの作成処理を終わる。フラグが「ＯＮ」である端
末情報レコードに至る前に、第１の種別のレコードを発
見したならば、少なくとも１つは未送信の第１の種別の
レコードがあることになる。この場合、エラー・ファイ
ル全体を複写し、送信用ファイルとする。第１の種別の
レコードがなければ、ヘッダー情報域４に相当するファ
イルを送信用ファイルとして作成する。

【００３２】処理６１：まず最初にエラー・ファイルの
ヘッダー情報域４から最新レコード位置４１を読み取
り、最新レコードであるレコード＃（ｎ）５７の格納開
始位置P(n)をポインターに設定する。

【００３３】処理６２：ポインターが示す位置から格納
されているレコードのレコード・ヘッダー５７１を読み
取る。

【００３４】処理６３：読み取ったレコード・ヘッダー
のレコード種５７４から当該レコードの種別を調べ、エ
ラーそのものに関する第１の種別のレコードかどうか判
断する。第１の種別である場合には、必要なレコードだ
として処理６４へ進み、第２の種別の場合は処理６５へ
進む。

【００３５】処理６４：第１の種別のレコードが少なく
とも１つ発見されたのであるから、エラー・ファイルそ
のものを複写して、送信用ファイルを作成して終わる。
このときエラー・ファイルには、フラグを「ＯＮ」とし
た端末情報レコードを、あらかじめ追加しておく。

【００３６】処理６５：レコード種５７４の値から、種
別が端末情報レコードかどうか判断する。端末情報レコ
ードなら処理６６へ、そうでないなら処理６８へ進む。

【００３７】処理６６：その端末情報レコード中のフラ
グを調べ、本発明のシステムによるものかどうか判断す
る。フラグが「ＯＮ」であれば、本発明のシステムによ
るものであるとして処理６７へ進む。「ＯＦＦ」ならば
旧システムが作成した端末情報レコードであるから、無
視して次の処理６８へと進む。

【００３８】処理６７：未送信の第１の種別のレコード
がない状態で、本発明のシステムにより作成された端末
情報レコードが発見されたのだから、ファイルのヘッダ
ー情報域のみからなるファイルを送信用ファイルとして
作成して終わる。

【００３９】処理６８：いま着目しているエラー・レコ
ードが、エラー・ファイルに蓄積されている最古のレコ
ードであるかどうか判断する。それ以上遡るべきレコー
ドがない場合、処理６７へ進みファイルのヘッダー情報
域のみからなるファイルを作成する。さらに遡るべきレ
コードがある場合は、処理６９へと進む。

【００４０】処理６９：処理６２で読み取ったレコード
・ヘッダーの情報から、前レコード長５７３がわかる。
この値をもとに現在着目しているレコードの１つ前に記
録されたレコードの格納開始位置を算出し、ポインター
をそこへ移動する。そして処理６２へと進み、過去のレ
コードへと遡るループを形成する。

【００４１】次に、エラー・ファイルに図５のような記
録がされている状態で、送信用ファイルを作成する手順
を図６のフローチャートに沿って説明する。処理６１お
よび処理６２により読み取り位置をP(n)に移動し、レコ
ード＃（ｎ）５７のレコード・ヘッダー５７１を読み取
るところまでは、前に述べたフローチャートの説明の場
合と同じである。

【００４２】ここでレコード＃（ｎ）５７が第１の種別
のレコードであれば、処理６３での判断に従ってファイ
ル全体を複写して（処理６４）終わる。レコード＃
（ｎ）５７が第２の種別のレコードであれば、処理６５
の判断に進む。ここで、レコード＃（ｎ−４）５３とレ
コード＃（ｎ−２）５５のみが端末情報レコードである
ため、レコード＃（ｎ）５７は端末情報レコードではな
い。こうして処理６８へ進むが、この時点ではレコード
＃（ｎ−４）５３ないしレコード＃（ｎ−１）５６が未
処理であるため、処理６９でポインターの値がP(n-1)に
変更される。

【００４３】レコード＃（ｎ−１）５６も同様に判断さ
れて、処理６２、処理６３、処理６５、処理６８、処理
６９と続くループを回る。次にレコード＃（ｎ−２）５
５は端末情報レコードであるから、処理６５から処理６
６へと進む。ところがこの端末情報レコードはフラグが
「ＯＦＦ」であるから、処理６８を通ってループへと戻
る。

【００４４】位置P(n-3)にあるレコード＃（ｎ−３）５
４についても、レコード＃（ｎ）５７等と同じ判断がな
される。もしこれも第１の種別のレコードでなければ、
ポインターの位置がP(n-4)に移り、レコード＃（ｎ−
４）５３のレコード・ヘッダー５７１が読み取られる。
ここでレコード＃（ｎ−４）５３は端末情報レコードで
あり、処理６５を経由して処理６６へと至る。ところが
レコード＃（ｎ−４）５３のフラグは「ＯＮ」であるか
ら、今度は処理６７へと進んでファイルのヘッダー情報
域のみを送信用ファイルとして作成して終わる。

【００４５】仮に、フラグが「ＯＮ」の端末情報レコー
ドも第１の種別のレコードも、エラー・ファイル中にな
かった場合、読み取られるレコードは位置 '0000 000C'
のレコード＃（１）５１まで遡る。そしてこの時点で、
処理６８の判断に従ってファイルのヘッダー情報域のみ
のエラー・ファイルが作られて（処理６７）、送信用フ
ァイルの作成処理が終わる。

【００４６】図７は送信用ファイルとして作られるエラ
ー・ファイルの例であり、(a) は図６のフローチャート
の処理６４で作られる場合、(b) は処理６７で作られる
場合である。(a) はレコードｉ個を含み、最新のレコー
ド＃（ｉ）５８はフラグ「ＯＮ」を持つ端末情報レコー
ドである。ファイルのヘッダー情報域にはこのレコード
に関する、最新レコード位置４１（P(i)）や最新レコー
ド長４２（L(i)）が格納される。(b) のファイルでは、
(a) のファイルと同じヘッダー情報域が作られるが、最
新レコード位置４１および最新レコード長４２には '00
00 0000'が、ファイル・サイズ４３にはファイルのヘッ
ダー情報域のサイズを示す '0000 000C'が格納される。

【００４７】図８および図９は、エラー・ファイルを送
信するときに参考情報として一緒に送信される、統計情
報ファイルおよび装置名ファイルの例である。それぞれ
(a)はエラー・ファイルが処理６４で作られた場合の形
式であり、処理６７の場合の形式が(b) である。どちら
の形式になるかは、エラー・ファイルが処理６４で作ら
れるか処理６７で作られるかにより決定され、統計情報
ファイルや装置名ファイル自身の内容には関係しない。

【００４８】統計情報ファイルには、ディスク装置や光
磁気ディスク装置などのファイル系入出力装置に関する
統計情報が記録される。この統計情報ファイルには、リ
ード回数やシード回数、リトライ回数などが装置ごとの
統計情報として格納されている。

【００４９】図８の先頭レコード位置71は、ファイルの
最も先頭に記録されたレコードである統計情報＃（１）
７４の格納開始位置 '0000 000C'を示している。先頭レ
コード長７２は、同じく統計情報＃（１）７４のレコー
ド長Lsを示す。ファイル・サイズ７３は、送信用の統計
情報ファイルのファイル長Lfs を示すもので、(b) の形
式の場合はファイルのヘッダー長 '0000 000C'が入る。

【００５０】形式(a) の場合は、このヘッダー部分の後
に統計情報＃（１）７４ないし統計情報＃（ｊ）７８が
続く。これらｊ個の統計情報レコードは、各ファイル装
置に対応するもので、端末装置の電源が切られるときに
上書き更新される。対象となるファイル装置数（ｊ個）
分の統計情報の後には、ファイル終端マーク７９として
'FFFF FFFF'という４バイトの情報が書き込まれる。

【００５１】図９の装置名ファイルは、エラー・ファイ
ル中の情報からエラーが起きた装置の装置名を知るため
のものである。ヘッダー部分には、ヘッダー・サイズ８
１として '0000 000C'が、ブロック・サイズ８２にLb、
ファイル・サイズ８３にはLfd が格納されている。形式
(b) では、ブロック・サイズ８２を '0000 0000'に、フ
ァイル・サイズ８３を '0000 000C'に書き換える。

【００５２】形式(a) では、この後に各装置ごとに装置
名などの情報を含むブロック＃（１）８４ないしブロッ
ク＃（ｋ）８８が記録される。装置数（ｋ個）分のブロ
ックの後には、ファイル終端マーク８９として 'FFFF F
FFF'という４バイトの情報が書き込まれる。

【００５３】以上で述べた実施例では、未送信の情報が
ある場合はエラー・ファイル全体を送信するようにして
いる。しかし、未送信のレコードのみを送るようにする
ことで、さらに送信される情報量を減らすことが可能で
ある。第２の実施例では、あらかじめ未送信のレコード
のみからなる中間ファイルを作成しておき、それに対し
て図６に示したような処理を行なうことで、送信用ファ
イルのサイズを小さくする。

【００５４】図１０は、中間ファイルの作成処理のフロ
ーチャートである。２つのポインター（ PtrS および P
trE ）を使い、ポインターの示す範囲（ PtrS 〜 PtrE
）のレコードを、未送信のレコードとしてエラー・フ
ァイルから抽出する。

【００５５】処理９１：まず最初にエラー・ファイルの
ヘッダー情報域４から最新レコード位置４１を読み取
り、最新レコードであるレコード＃（ｎ）５７の格納開
始位置P(n)を各ポインター（ PtrS および PtrE ）に設
定する。

【００５６】処理９２：ポインター PtrS が示す位置か
ら格納されているレコードのレコード・ヘッダー５７１
を読み取る。

【００５７】処理９３：レコード種５７４の値から、種
別が端末情報レコードかどうか判断する。端末情報レコ
ードなら処理９４へ、そうでないなら処理９６へ進む。

【００５８】処理９４：その端末情報レコード中のフラ
グを調べ、本発明のシステムによるものかどうか判断す
る。フラグが「ＯＮ」であれば、本発明のシステムによ
るものであるとして処理９５へ進む。「ＯＦＦ」ならば
旧システムが作成した端末情報レコードであるから、無
視して次の処理９６へと進む。

【００５９】処理９５：本発明のシステムにより作成さ
れた端末情報レコードが発見されたのであるから、これ
以上遡って抽出すべき未送信のレコードはない。２つの
ポインターが示す範囲（ PtrS 〜 PtrE ）のレコード、
すなわち図５の例で言うと、レコード＃（ｎ−４）５３
ないしレコード＃（ｎ）５７を抽出し、ファイルのヘッ
ダー情報域を付けて中間ファイルとする。

【００６０】処理９６：いま着目しているエラー・レコ
ードが、エラー・ファイルに蓄積されている最古のレコ
ードであるかどうか判断する。それ以上遡るべきレコー
ドがない場合、処理９５へ進み、２つのポインターが示
す範囲（ PtrS 〜 PtrE ）のレコードを抽出し、ファイ
ルのヘッダー情報域を付けて中間ファイルとする。さら
に遡るべきレコードがある場合は、処理９７へと進む。

【００６１】処理９７：処理９２で読み取ったレコード
・ヘッダーの情報から、前レコード長５７３がわかる。
この値をもとに現在着目しているレコードの１つ前に記
録されたレコードの格納開始位置を算出し、ポインター
（ PtrS ）をそこへ移す。そして処理９２へと進み、過
去のレコードへと遡るループを形成する。

【００６２】以上のように、未送信のレコードのみから
なる中間ファイルを作成し、そのファイルを元に図６の
処理により送信用ファイルを作成する。こうすること
で、未送信のレコードを送信する場合の情報量を減らす
ことができる。

【００６３】第３の実施例として、図１１に示す選択的
送信処理について説明する。送信用ファイルは、図７な
いし図９で示した(a) または(b) の形式で作成されてい
る。このうち形式(b) のファイルは、実質上はエラー情
報をなんら含まないため、あえて送信する必要はない。
これらのファイルの送信を中止することで、システムに
おける送信処理の回数を減らすことができる。

【００６４】処理１０１：送信用エラー・ファイルのフ
ァイル・サイズ４３を読み込み、ヘッダー・サイズ( '0
000 000C')と比べて大きいかどうか判断する。ファイル
・サイズ４３がヘッダー・サイズより大きい場合は処理
１０２へ進み、そうでなければヘッダーのみのファイル
であるから、送信処理を行なわずに処理を終わる。

【００６５】処理１０２：未送信のレコードを含むファ
イルであるから、送信用ファイル３つ（エラー・ファイ
ル、統計情報ファイル、装置名ファイル）をホスト装置
２へ送信する。

【００６６】

【発明の効果】以上の説明のとおり、本発明の端末情報
収集システムは、あらたに発生した情報がない端末装置
から送られるファイルを、ヘッダー情報域程度のサイズ
にするので送信する情報量を格段に削減できる。また、
従来のシステムと同様に送信用ファイルを作るため、従
来システムを適用した端末装置と本発明を適用した端末
装置とが共存する形でのシステム構築も可能で、システ
ム全体の効率が良く従来装置との互換性に優れたシステ
ムを提供することができる。

【００６７】また、ファイルの送信において、送信用フ
ァイルがヘッダー・サイズである場合には送信しないよ
うにすることもできる。そうすることで送信されるファ
イルの数が減り、送信に要する処理の回数（すなわちシ
ステムに対する負担）を少なくできる。

【００６８】特に、蓄積された情報がエラー情報である
場合、ホスト装置での集中管理には不要な第２の種別の
情報が、端末装置に蓄積されていることがある。そのよ
うな情報のみが新規に蓄積されている場合、それらを対
象から除くことで送信すべき情報量を少なくし、さらに
効率を向上させることができる。

【図面の簡単な説明】

【図１】本発明の原理説明図。

【図２】端末情報収集処理を示すフローチャート。

【図３】エラー・ファイルの形式を示す図。

【図４】エラー・レコードの形式を示す図。

【図５】エラー・ファイルの例を示す図。

【図６】送信用ファイルの作成処理のフローチャート。

【図７】送信用エラー・ファイルの例を示す図。

【図８】送信用統計情報ファイルの例を示す図。

【図９】送信用装置名ファイルの例を示す図。

【図１０】中間ファイルの作成処理のフローチャート。

【図１１】選択的送信処理のフローチャート。

【符号の説明】

１端末装置２ホスト装置４ヘッダー情報域５レコード格納域

Claims

【特許請求の範囲】

【請求項１】端末装置（１ａないし１ｂ）内に蓄積さ
れた情報（１４）をホスト装置（２）に転送し、該蓄積
された情報（１４）を該ホスト装置（２）で集中管理す
る情報処理システムにおいて、前記蓄積された情報（１４）中に未送信の情報があるか
どうかを検出する未送信情報検出手段（１１）と、前記未送信情報検出手段（１１）が前記未送信の情報を
検出した場合は、少なくとも該未送信の情報に該未送信
の情報を管理するための管理情報を付加して送信情報
（１５）とし、前記未送信の情報を検出しない場合は管
理情報のみを送信情報（１５）として作成する送信情報
作成手段（１２）と、前記送信情報作成手段（１２）により作成された前記送
信情報（１５）をホスト装置（２）に送信する送信手段
（１３）と、から構成される端末情報収集システム。
【請求項２】前記送信手段（１３）は、前記送信情報
（１５）の大きさが所定の値より大きいかどうか判別す
る判別手段を含み、該所定の値より大きい場合のみ前記
送信情報（１５）をホスト装置（２）に送信することを
特徴とする、請求項１記載の端末情報収集システム。
【請求項３】前記蓄積された情報（１４）が、前記端
末装置（１ａないし１ｂ）に関して発生したエラー情報
であり、前記未送信情報検出手段（１１）は、該エラー
情報のうち所定の種別の情報のみを対象として前記未送
信の情報を検出することを特徴とする、請求項１または
２記載の端末情報収集システム。