JPS62196943A - デ−タ転送方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 ［産業上の利用分野１ 本発明は、例えばコンピュータ等の間でのデータ転送方
式に関する。

［従来の技術］ コンピュータとコンピュータの間でデータを送受信する
場合、両コンピュータ間でプロトコルを決めてデータの
送受信を行なう。このようなプロトコルにおいては、デ
ータ転送に誤りが生じた場合の再送の手順を予め決めて
おき、信頼性向上に努めなければならない。この再転送
の手順は実際にはかなり複雑である。又、コンピュータ
子コンピユータ間でのデータ転送は転送すべきデータの
発生頻度は少ないが、転送データが両コンピュータにお
いて独立して非同期で発生するために、全二重方式を採
用する場合がある。

［発明が解決しようとする問題点コ このように従来技術においては、実際には余り発生する
ことの少ない伝送エラーを考慮して、従って余り使われ
る事の少ない複雑なデータ再転送のプロトコルを組込ま
ねばならず、効率的ではない。又、特に全二重でデータ
転送を行う場合にはハードウェアやクリティカルなタイ
ミングの問題で正常動作させるまでにかなりの開発時間
を必要としていた。

本発明は上記従来技術、の欠点に鑑みてなされたもので
、単純なプロトコルであっても信頼性のあるデータ転送
方式を提案する事を課題とする。

［問題点を解決するための手段］ 上記課題を達成するの実施例の構成を第１図（ａ）に、
その再送プロトコルを第１図（ｂ）に示す。第１図（ａ
）は送信側コンピュータシステム１０から受信側コンピ
ュータシステム２０にデータを転送する場合を図示する
。コンピュータシステム（１０，２０）は夫々、時間監
視手段として時間間隔監視部（ｔｔ、２１）を、送受信
手段として送受信バッファ（１２，２２）と送受信部（
１３，２３）とを有する。

［作用］ 第１図（ａ）の実施例のデータ転送方法を第１図（ｂ）
に時系列で示す。図中、矢印方向が時間の流れを示し、
破線から破線の間隔が所定の時間間隔を示す。これらの
時間間隔をＩ、ＩＩ・・・で特定する。例えば時間間隔
工でのデータＡの送信が行われたとしても、次の時間間
隔ＩＩで自動的にデータＡを再送する。この再送は障害
発生の有無にかかわらず、新たに送信すべきデータＢが
発生するまで繰返される。従って、受信側のコンピュー
タシステム２０は少なくとも２個以上のデータを受は取
った事となり、例え時間間隔Ｉで障害が発生していたと
しても、２度目の再送で無事正常に受信している可能性
は極めて高い。

［実施例コ 以下添付図面を参照しながら本発明に係る実施例を更に
詳細に説明する。

〈実施例の概要〉 第１図（ａ）は送信側コンピュータシステム１０と受信
側コンピュータシステム２０との間でデ二夕を転送する
場合を図示する。コンピュータ間のインターフェースは
一例としてＲ５−２３２Ｃインタフエースを採用した。

データ転送は全二重で行なわれる。

く通信インターフェース〉 第２図は送受信部（１３，２３）における全二重でのＲ
３−２３２Ｃインタフエースでの各信号の接続を表わす
。各記号はＣＣＩＴＴ勧告Ｖ２４に基づいている。便宜
上、モデム（変復調装置）は使わずに直接接続している
。

〈送受信データのフォーマット〉 第３図は本実施例において、コンピュータシステム（１
０，２０）間で授受されるデータのフォーマットを示す
ものである。このフォーマットのデータは送信すべきデ
ータと受信したデータとについては同一である。そこで
、本実施例では全二重で動作をするために第３図に示し
た毎く送信用と受信用のバッファ１つづつが夫々のデー
タ格納域（１６，２６）に確保されている。

又、より詳細な実施例であるところの第４図では、ホス
トコンピュータ３０（３１）とＵＳＡＲＴ　　（ＬＩＮ
ＩＶＥＲ５ＡＬ　　５ＹＮＣＨＲＯＮＯ１ｌＳ　　ＡＳ
ＹＮＣＨＲＯＮＯＵＳ　　ＲＥｆｌ：ＥＩＶＥＲＴＲＡ
ＮＳＭＩＴＴＥＲ）　　５４とで非同期でデータ授受を
行うために第３図に示したバッファを２つづつ、従って
計４つ用意している。第３図のフォーマットについて説
明すると、スタートフラグは送信データのヘッディング
の開始を示すもので、通常はＳ　ＯＨ，コードである。

ＳＯＨコードに続いて送信通番（後述する）があり、続
いて送信テキストの開始を示すＳＴＸコード、送信テキ
スト、ＥＴＸコードそして誤り監視用（又は訂正用）の
ＢＣＣ（又はＥＣＣ）コードが続く。誤り監視は上記の
ＢＣＣコード又はＥＣＣコードに基づいたチェックの他
に、フォーマット（第３図）順の受信がなされているか
のチェック等を行ってもよい。

〈実施例の動作概要〉 第１図（ａ）について説明する。コンピュータシステム
（１０，２０）は夫々、時間間隔監視部（１１，２１）
と送受信バッファ（１２，２２）と、送受信部（１３，
２３）とを有する。送受信バッファ（１２，２２）内に
はデータ格納域（１６，２６）と送信通番格納域（１４
，２４）及び受信通番格納域（１５，２５）等がある。

送受信バッファには第３図に示された一連のデータが格
納される。通番とは送信又は受信のシーケンスの確認を
確保するための番号で、通常連続した番号を送信用と受
信用に別個に設ける。

実施例のデータ転送方法を第１図（ｂ）に時系列で示す
。図中、矢印方向が時間の流れを示し、破線と破線との
間隔は一定の時間間隔を示す。これらの時間間隔を１．
ＩＩ、・・・で特定する。この時間間隔はコンピュータ
間で送受信すべきデータの発生頻度から決定されるべき
もので、発生頻度が高ければそれに応じて間隔を短くす
る。

例えば時間間隔■でテキストＡが発生したとすると、デ
ータ格納域１２にはテキストＡと送信通番“１”が格納
され、コンピュータシステム２０に送信される。もちろ
ん、受信側のコンピュータシステム２０の受信通番格納
域２５にも′１″が予め格納されている。送信側コンピ
ュータシステム１０は受信側コンピュータシステム２０
に正常にデータが送信できたかをチェックするシーケン
スを従来のように設けない。即ち、受信側コンピュータ
システム２０は正常、異常受信にかかわらず応答は返さ
ない。図示したようにこの送信時に伝送上の障害が発生
していたのなら、受信側コンピュータシステム２０には
データは正常に到達していない筈である。

時間間隔ＩＩが経過してもその間に送信側コンピュータ
システム１０に新たな送信データが発生していないのな
ら、送信側コンピュータシステム１０はテキストＡ十送
信通番“１″を再転送する。

次の時間間隔ｍ内にテキストＢが発生すると、送信通番
を“１″だけインクリメントしてテキストＢ十通番“２
”を送信する。間隔■には新たなデータが発生していな
いのでテキストＢ十通番゛２′′を再送する。

もし、図に示した如く、最初のテキストＡ十通番“１”
を送信中に障害が発生し、受信側コンピュータシステム
２０が正常に受信できなかったとしても、２度目の受信
で完全なデータを受信できるのである。一方、テキスト
Ｂについてみれば受信側コンピュータシステム２０は同
一のテキストを２度以上受信した可能性がある。しかし
、これは受信通番チェックで排除できる。即ち、受信側
コンピュータシステム２０は受信する毎に、前述のＢＣ
Ｃコードのチェックで誤りがなければ受信通番と自己の
受信通番格納域２５に格納されていた受信通番とを照合
する。両者が同一でなければ新たな別個のテキストを受
信したとして、受信通番格納域２５の内容を“１”だけ
インクリメントする。従って、受信通番が同一であった
ならば重複して受信したものと判断できるので、同一テ
キストの重複取り込みを排除できる。

（ＲＳ２３２制御部〉 さて第４図はより詳細な実施例のブロック構成図である
。ホストコンピュータ３０はＲ３２３２Ｃインターフエ
ースを行うＲ５２３２制御部６０を介して、更に伝送線
６１．６２　（ＲＤ、ＳＤ）を通じて他のコンピュータ
システム２０と接続している。ＦｔＳ２３２制御部６０
の詳細は、ホストコンピュータとインターフェースする
ホストインターフェース４０、ホストコンピュータ３ｏ
とＲ３２３２制御部６０とでデータ転送するＤＭＡ５５
．２つの送信用バッファ（ＳＢ）である＃１ｓＢ　（Ｓ
ＥＮＤ　ＢＵＦＦＥＲ）　、　＃　２　Ｓ　Ｂ　、　２
　つの受信用バッフ７　（ＲＢ）　であル＃　Ｉ　ＲＢ
　（ＲＥＣＥＩＶＥ　ＢＵＦＦＥＲ）。

＃２ＲＢ、前述のシリアル通信インターフェースである
ＬＩＳＡＲＴ５４、プログラム可能なタイマ４４、そし
て上記の構成要素全体の制御を実行するＭＰＵ４１、そ
の制御実行上のデータを格納するＲＡＭ４２と、後述す
る制御手順のプログラム（第７図〜第９図）を格納する
ＲＯＭ４３等である。

〈制御のためのフラグ等〉 第５図はＲＡＭ４２内に確保されている制御上必要な色
々なフラグ等を示す。順に説明すると、３０７ＭＲ７０
は送信データを一定時間毎に送るためのタイミングを形
成するタイマ（ＳＥＮＤ　ＴＩＭＥＲ）である。一方、
ＲＶＴＭＲ７１とは本実施例では必ず前記一定時間毎に
データが授受されるから受信側テ（７）監視時間（ＲＥ
ＣＥＩＶＥ　ＴＩＭＥＲ）　ｉ’ある。５ＴＯＶＦ７２
．ＲＴＯＶＦ７３は上記のタイマカオーバフローした事
を示すフラグ（ＳＥＮＤ　ＴＩＭＥＲ０ＶＥＲＦＬＯＷ
　ＦＬＡＧ、ＲＥＣＥＩＶＥ　ＴＩＭＥＲ０ＶＥＲＦＬ
ＯＷ　ＦＬＡＧ）である。＃Ｉ　ＳＢＦ　（７４）、＃
２ＳＢＦ　（７５）。

＃ＩＲＢＦ　（７６）、＄２ＲＢＦ　（７７）は夫々前
述の＃ＩＳＢ　（５０）、＃２３Ｂ　（５１）、＃ＩＲ
Ｂ　（５２）、＃２ＲＢ　（５３）に有効なデータが格
納されている事を示すフラグ（ＳＥＮＤ　ＢＵＦＦＥＲ
ＦＵＬＬ　ＦＬＡＧ、ＲＥＣＥＩＶＥ　ＢＵＦＦＥＲＦ
ＵＬＬ　ＦＬＡＧ）テある。

１２ＸＣＦ　（７Ｂ）は第２受信バツフアからデータが
ホストコンピュータに送られた事を示すフラグ　（＃２
ＲＥＣＥＩＶＥ　　ＢＵＦＦＥＲＴＲ八へ５ＦＥＲＥＤ
　　ＦＬＡＧ）、　　ＲＰＴＣ７９（ＲＥＰＥＡＴ　Ｃ
０ＵＮＴＯＲ）は送信側が同一データを送信した回数を
記録するカウンタである。このＲＰＴＣ７９は所定のカ
ウント値に達するとオーバフローする。従って、このＲ
ＰＴＣ７９がオーバフローした事により、少なくとも所
定の回数だけ同一データを再送した保証になる。又、Ｒ
ＰＴＣ７９がオーバフローして更に同一データを再送し
続けても、ホスト側から新たなデータが送られて来ない
かぎり、いつこうに差支えない。ＩＲＥＲＦ８０は回復
不能なエラーが発生した事を示すフラグ（ＩＲＲＥＣＯ
ＶＥＲＡＢＬＥ　ＥＲＲＯＲＦＬＡＧ）、ＬＸＴＲＮＯ
８１はＲ５２３２制御部６０からホストコンピュータへ
最新に転送された受信データの通番（ＬＡＳＴＴｎＡＮ
ＳＦＥＲＥＤ　ＴＲＮＯ）である。

くバッファ管理〉 第６図（ａ）は送信時の送信バッファの使い方を示す図
であり、第６図（ｂ）は同じく受信時の受信バッファの
使い方を示す。第６図（ａ）に示すように、送信データ
のバッファへの格納は＃ｌ５Ｂ（５０）と＃２３Ｂ　（
５１）の両者が°°空°。

であるときは＃２ＳＢ（５１）に、＃２３Ｂ（５１）が
“満”であるときは＃ｌ５Ｂ（５０）に格納される。５
Ｄ６２上に送信される時は常に＃２ＳＢ（５１）からＵ
ＳＡＲＴ５４を介して送出される。このバッファ管理は
＄ｌ５ＲＦ　（７４）。

＃２ＳＢＦ　（７５）のフラグをみて行われる。

第６図（ｂ）によると、受信時は、ＵＳＡＲＴ５４がＳ
ＯＨを受信すると、＃ＩＲＢ（５２）にバッファを確保
しようとする。もし＃ＩＲＢ（５２）が“満”であるな
らば＃ＩＲＢ（５２）の内容を＃２ＲＢ　（５３）に穆
してから＃ＩＲＢ（５２）に受信データを格納する。又
、Ｒ５２３２制御部６０からホストコンピュータへデー
タ転送するときは先ず＄２ＲＢ　（５３）に格納されて
いるデータを転送し、更に＃ＩＲＢ（５２）に格納され
ている受信データがあるときはその内容を＃２ＲＢ（５
３）へ穆してからホストコンピュータへ転送する。ここ
で、＃ＩＲＢＦ　（７６）、＃２ＸＣＦ　（７８）、Ｌ
ＸＴＲＮＯ８１はホストコンピュータ３１へ転送される
データの順序の整合性を確保するために使われる。

〈制御手順〉 以下制御手順についてフローチャートを用いて説明する
。

くタイマルーチン〉 第７図（ａ）、（ｂ）はそれぞれＳＤＴＭＲ７０とＲＶ
ＴＭＲ７１のカウントルーチンである。

夫々、１ずつカウントアツプしてカウンタがオーバフロ
ーしたら（ステップＳ４．ステップ５１２）、夫々５Ｔ
ＯＶＦ７２とＲＴＯＶＦ７３をセットする。これらの２
つのフローはタイマ４４を使って、メインルーチンとは
並行して実行されメインルーチンへは割込み処理により
なされる。

く送信ルーチン〉 第８図（ａ）はデータ送信のためのメインルーチンであ
る。先ず、ステップＳ２０で５ＴＯＶＦ７２がセットし
ているかを調べる。即ち、送信のための所定の時間（Ｓ
Ｉ）ＴＭＲ）が経過するのを待つわけである。かかる時
間が経過していないときはステップＳ４０へ進み、ホス
トコンピュータ３０からのデータがあるかを調べる。ホ
ストコンピュータからのデータの有無はホストインター
フェース４０がＭＰＵ４１に割込みをかける事によって
知る。このような割込みにより、ホストコンピユータか
らの送信データが存在するのならば、ステップＳ４２へ
進み、ホストコンピュータからのデータを送信バッファ
に格納するためのホスト→ＳＢサブルーチンステップＳ
４２を実行する。

このホスト→ＳＢサブルーチン実行後、＃ｌ５Ｂ（５０
）又は＃２３Ｂ（５１）に送襦データ格納して、致命的
なエラーが無ければ（ステップ５４６）、ステップＳ２
０へ戻って、５ＴＯＶＦ７２がセットするのを待つ。

ホストコンピュータ→ＳＢサブルーチンを第８図（ｂ）
を用いて説明する。前述したように、このサブルーチン
は送信データのバッファへの格納を、＃Ｉ　ＳＢ　（５
０）と＃２５Ｂ　（５１）の両者が“空“であるときは
＃２３Ｂ（５１）に、＃２ＳＢ（５１）が“満”である
ときは＃ｌ５Ｂ（５０）に格納するというものである。

そこで先ず、ステップＳ５０でＤＭＡ５５を起動する。

ステップＳ５２ではバッファ管理のために９２ＳＢＦ　
（７５）のセット状態を調べる。＃２３Ｂ（５１）にデ
ータが格納されていなければ、ステップＳ５４へ進み、
＃ｌ５ＢＦ（７４）のセット状態を調べる。このとき＠
ｌ５ＢＦ（７４）がセットしていれば回復不能なエラー
としてステップＳ７４でＩＲＥＲＦ８０をセットする。

これは本実施例では＃２５Ｂ（５１）が“空”であると
きにホストコンピュータからのデータが発生したときは
＃ＩＳＢ　（５０）ではなく＃２３Ｂ　（５１）へ格納
するようにバッファ管理をしているからである。さてス
テップＳ５４で＃ｌ５Ｂ（５０）が“空”であることが
判明したら、ステップＳ５６でＤＭＡ５５を介してホス
トコンピュータ３０から＃２ＳＢ（５１）にデータを転
送し、ステップＳ５７で送信通番格納域１４の内容を更
新するとともに送信データ中の送信通番（第３図参照）
をセットして、ステップ３５Ｂで転送終了で＃２３ＢＦ
　（７５）をセットする。

一方、ステップ５５２で＃２ＳＢＦ　（７５）がセット
していればステップＳ６０へ進み、＃ｌ５ＢＦ（７４）
のセット状態を調べる。このような場合とは、前記のＳ
ＤＴＭＲ７０のタイムアウト前に続けてホストコンピュ
ータから２つのデータが来たときである。この２度目の
データに対してステップＳａＯで＃ｌ５ＢＦ（７４）が
セットしていなければステップＳ７０で＄ＩＳＢ　（５
０）にホストコンピュータからのデータを格納し、ステ
ップＳ７１では送信通番を更新し、ステップＳ７２で＃
ｌ５ＢＦ　（７４）をセットする。

ステップＳ６０で＃ｌ５ＢＦ（７４）がセットしている
ときは、ステップ３６２でＲＰＴＣ７９がオーバフロー
しているかを調べる。このＲＰＴＣ７９は、同一データ
を少なくともＲＰＴＣ７９に保持された回数だけ５Ｄ６
２上に再送信するためにあるのであるから、ＲＰＴＣ７
９がオーバフローしていないときは＃２ＳＢ（５１）内
のデータは捨てるわけにいかないので、ステップＳ７４
で回復不能エラーと判断してＩＲＥＲＦ８０をセットす
る。もつとも、この場合はバッファを２つしか用意して
いないために、ＩＡ埋速度がホストコンピュータ側に遅
れたものであるから、回復不能エラーとしないでホスト
コンピュータ側にデータ転送を待たせるようにしてもよ
い。

一方、ステップＳ６２でＲＰＴＣ７９がオーバフローし
ていれば＃２ＳＢ（５１）内のデータは少なくとも所定
回数送信しているのであるから、＃：ＳＳＢ　（５１）
内のデータを捨てて＃ｌ５Ｂ（５０）内のデータを生か
すためにステップＳ６４で＃Ｉ　ＳＢ　（５０）の内容
を＃２５Ｂ　（５１）へ移送する。そして、ステップＳ
６６では＃Ｉ　５ＢＦ（７４）をリセットしステップＳ
６８ではＲＰＴＣ７９を０″にする。

以上のようにして、ＳＤＴＭＲ７０の時間内におけるホ
ストコンピュータからの転送発生頻度に応じて、＃２３
Ｂ（５１）又は＃ｌ５Ｂ（５０）及び＃２ＳＢ　（５１
）の両方に送信データが格納される。

そこで第８図（ａ）に戻って、送信バッファ（Ｓ　Ｂ）
にデータが格納されて後、ステップＳ２０で５ＴＯＶＦ
７２がセットしているときは、ステップＳ２２へ進み＠
２５ＢＦ　（７５）がセットしているかを調べる。＃２
３ＢＦ　（７５）がセットしていなければステップＳ４
４へ進み５ＴＯＶＦ７２をリセットしてステップＳ２０
へ戻る。さてステップ３２２で＃２ＳＢＦ　（７５）が
セットしているときはステップＳ２４へ進み、ＲＰＴＣ
７９がオーバフローしているかを調べる。ＲＰＴＣ７９
がオーバフローしていないときは、ステップＳ２８でＲ
ＰＴＣ７９をカウントアツプして、ＲＰＴＣ７９がオー
バフローしているときはそのままで、ステップＳ３０に
進み＃２ＳＢ（５１）内の送信データをＵＳＡＲＴ５４
を介して送出する。こうして、Ｒ５２３２制御部６０は
、ホストコンピュータから次の新たなデータが送られて
くるまで、同じ送信データの送出を繰返す。

さて第８図（Ｃ）は第８図（ａ）のステップＳ３０の詳
細であり、ＵＳＡＲＴ５４を介して＃２ＳＢ（５１）の
内容を１バイトづつ送出するサブルーチンである。その
概略は、ステップＳ７３で＃２ＳＢ（５１）から１バイ
トづつ読出してステップＳ７４でＵＳＡＲＴ５４に送る
。ＵＳＡＲＴ５４は独自の内部制御により第２図に示し
たインターフェース信号等を監視しながら１バイトづつ
５Ｄ６２上に送出する。１バイト送出すれば、ＵＳＡＲ
Ｔ５４はＭＰＵ４１に対して割込みをかけて、更に１バ
イト要求する等の手順は周知のところである。このよう
な制御手順をステップＳ７５でＥＴＸ送出時まで繰返す
。この間に送信通番。

ＳＴＸ、テキストの送出、又ＢＣＣコードの計算等を行
っている。ステップ３７７では計算していたＢＣＣコー
ドを送出する。ＢＣＣコードの計算はＳＴＸの次のバイ
トからＥＴＸまでの計算である。全送信データを送出後
ステップＳ７７で＃２ＳＢＦ（７５）をリセットする。

〈受信手順〉 第９図（、）は受信メインルーチンのフローチャートで
ある。この受信ルーチンは上記説明した送信ルーチンと
は独立した制御でなされる。ステップＳ８０でＲＴＯＶ
Ｆ７３（７）セットを調／＜　ＲＶＴＭＲ７１がタイム
アウトしたかを調べる。セットしていたならばステップ
Ｓ８２でＲＴＯＶＦ７３をリセットして、ステップＳ８
４で受信側が少なくとも１回データを受信したかを調べ
る。これは送信側がひとたび送信データを送信した後は
常に所定時間（ＳＤＴＭＲ７０の時間）毎に必ず送信デ
ータを送出するものであり、このために受信側ではＲＶ
ＴＭＲ７１の時間監視により送信側と受信側との間の障
害を監視する事が可能となる。

従って、一番最初の送信データでない限りこのＲＶＴＭ
Ｒ７１のタイマがタイムアウトした時は障害としてステ
ップＳ８６でＩＲＥＲＦ８０をセットするのである。

一方、ステップＳ８０でＲＴＯＶＦ７３がセットしてい
なければ、ステップＳ８８へ進みインターフェース信号
ＣＤ（キャリアディテクト）を調べる。ＣＤ信号が存在
していなければステップＳ９２へ進み、＃２ＸＣＦ　（
７８）のセット状態を調べる。このフラグは＃２ＲＢ　
（５３）内にホストコンピュータに転送すべき受信デー
タがある事を示すフラグである。さてこの＃２ＸＣＦ　
（７８）がセットしていなければステップＳ９６からス
テップＳａＯへ戻って、ＲＶＴＭＲ７１のタイムアウト
か、ＣＤ信号がくるのを待つ。送信側から送信データが
送られてきたときはＣＤ信号が°″１゛°となり、ＵＳ
ＡＲＴ５４がＭＰ（Ｊ４１に受信割込みをかける。する
と、ステップＳ９０のデータ受信サブルーチンを実行す
る。このサブルーチンは第９図（ｂ）にその詳細を示す
。

ステップ５１００でＵＳＡＲＴ５４からの１バイトづつ
を、そのコードを調べつつ（ステップ５１０２）、受信
バッファ（＃　Ｉ　Ｒ，Ｂ　（５２）　）に格納する（
ステップ５１０６）ものである。さてステップ５１０２
ではその受信キャラクタによって制御ステップが分れる
。ＳＯＨコードを受信したときは＃ＩＲＢ（５２）に受
信データのためのバッファを確保するために、ステップ
５１０４でバッファ確保サブルーチンを実行する。ＳＴ
Ｘコード、ＥＴＸコード、テキスト、通番等はそのまま
＃ＩＲＢ（５２）に受信した１バイトを格納（ステップ
５１０６）する。ＢＣＣコードのときは＃ＩＲＢ（５２
）に格納（ステップ３１０７）後、受信完了処理サブル
ーチン（第９図（Ｃ））を実行する。ＢＣＣコードはＥ
ＴＸ受信後の次のキャラクタコードをＢＣＣとみなして
いる。

さてこのようにＢＣＣコードまで＃ＩＲＢ（５２）に格
納されると、第９図（Ｃ）の受信完了処理を実行する。

これは先ずステップ５１２０でＢＣＣエラーの有無、ス
テップ５１２２・でフォーマットエラーの有無を調べ、
それらのエラーが無ければステップ５１２４で通番照合
を行う。これは受信通番格納域２５に格納されている受
信通番と今受信されたデータ中の受信通番（第３図）と
を照合するものであり、もし同一通番であれば、このよ
うなデータは既に正常に受信されホストコンピュータ３
１に転送されているか少なくとも＃２ＲＢ（５３）に格
納されている筈のものであるから、何の処理も行わずに
、ステップ３９６へリターンする。

一方、ステップ５１２６で同一通番でないことが判明し
た場合は、これは新規な受信データであるから、ステッ
プ５１２８へ進み受信通番格納域２５の内容を更新する
。そしてこの受信データを＃２ＲＢ　（５３）に転送し
てもよいかを確認するために、＃２ＸＣＦ　（７８）の
セット状態を調べる。前述したように、＃２ＸＣＦ　（
７８）は＃２ＲＢ（５３）に格納されているデータがホ
ストコンピュータ３１に転送されているか否かを反映す
るフラグであるから、この＃２ＸＣＦ　（７８）がセッ
トしていないときは、＃ＩＲＢ（５２）の内容を移送せ
ずにこのままにして、ステップＳ９６ヘリターンする。

従って、このときは＃ＩＲＢ（５２）、＃２ＲＢ　（５
３）に有効なデータが格納されているのであるから、こ
れらのデータがホストコンピュータに転送されない内に
再度ＵＳＡＲＴ５４が受信すると回復不能のエラーとな
る（ステップ５１７４）。

さてステップ５１２８で＃２ＸｃＦ（７８）がリセット
しているときはステップ５１３２で＃ＩＲＢ（５２）の
内容を＃２ＲＢ　（５３）へ穆す。

そしてステップ５１３４で＃２ＸＣＦ　（７８）をリセ
ットする。＃２ＲＢ　（５３）に今格納されているデー
タは新規な受信データであるからである。

第９図（ｄ）によりバッファ確保サブルーチンを説明す
る。第９図（ｂ）のステップ５１０２でＳＯＨコードの
受信した事が判別したらステップ５１７０に進み、＄Ｉ
ＲＢＦ　（７６）がセットしているかを調べる。セット
していなければ、＃ＩＲＢ　（５２）は“空”であるか
ら、そのままステップ５１０６へリターンする。セット
してぃれば、ステップ５１７２で＃２ＸＣＦ　（７８）
のセット状態を調べる。＃２ＸＣＦ　（７８）がリセッ
トしていれば前述したように回復不能のエラーとしてス
テップ５１７４でＩＲＥＲＦ８０をセットする。＃２Ｘ
ＣＦ　（７８）がリセットしていればステップ３１７６
で、＃ＩＲＢ（５２）を“空°。

にするために＃ＩＲＢ（５２）の内容を＃２ＲＢ（５３
）に移す、ステップ５１７８では＃ＩＲＢＦ（７６）を
リセットする。

第９図（ａ）　に戻って、ＲＴＯＶＦ７３がセットして
おらず、かつ信号ＣＤが“１”でなく又ステップＳ９２
で＃２ＸＣＦ　（７８）７５（リーｔ’ットＬ。

ている場合について説明する。このときはステップＳ９
４でＲＢ→ホストコンピュータサブルーチンを実行する
。このサブルーチンは第９図（ｅ）に示しであるように
、先ずステップ５１４２で最終転送通番（ＬＸＴＲＮＯ
８１）のチェックを実行する。これはホストコンピュー
タ３１に転送されるデータが常にシーケンシャルな、抜
けのない、又重複もない事を確保するためである。この
ようなエラーがあった場合は回復不能であるから、ステ
ップ５１４６へ進みＩＲＥＲＦ８０をセットする。エラ
ーがなければステップ８１４８へ進み、ＤＭＡ５５を起
動して、＃２ＲＢ　（５３）の内容をホストコンピュー
タ３１へ転送する（ステップ５１５０）。ステ”／ブ５
１５２ではＬＸＴＲＮＯ８１を更新する。次にステップ
５１５４で＃Ｉ　ＲＢＦ　（７６）のセット状態を調べ
る。前述したように＃ＩＲＢＦ（７６）は新規なデータ
が＃ＩＲＢ（５２）に格納されている事を示すフラグで
あるから、このフラグがセットしているときはステップ
５１５６で＃ＩＲＢ（５２）の内容を＃２ＲＢ　（５３
）に穆し、ステップ５１５８で＃ＩＲＢＦ（７６）をリ
セットし、ステップ５１４２に戻ってこの＃２ＲＢ　（
５３）のデータをホストコンピュータ３１に転送する。

ステップ５１５４で＃２ＸＣＦ　（７Ｂ）がセットして
いればステップＳ　１６０で＃２ＸＣＦ　（７８）をセ
ットして、ステップＳ９６へリターンする。

くエラー処理について〉 Ｉ　ＲＥＲＦ８０がセットしたときは、原則的に回復不
能のエラーである。送信側で発生したこのエラーは主に
ホストコンピュータからＲ３２３２制御部６０へのデー
タ転送とＦＬＳ２３２制御部６０による５Ｄ６２へのデ
ータ送出との同期が取れないときに発生するものである
から、このような場合はエラーとせずにホストコンピュ
ータ側がデータ転送を待つようにすればよいことは前述
した通りである。一方、受信側にもこのような同期がと
れないために発生するエラー（ステップ５１７４）があ
るが、この回復不能のエラーに対しても前述の送信側で
とる処置を適用すればよい。又、上記実施例ではバッフ
ァの数を２つずつ用意したが、両ホストコンピュータ間
で発生するデータ量を予想してバッファの数を増減し、
又は送信間隔（Ｓ　ＤＴＭＲ７０の間隔）を伸縮するよ
うにしてもよい。

しかし、ステップ５１４６で発生したエラーはデータ抜
けの可能性があるので回復のしようがなく、従ってこの
ようなばあいは、受信側のＲ３２３２制御部６０はＲＤ
６１上に例えばブレーク信号を送出するか、又はこのよ
うなエラーが発生した事を報知するデータを送信側に送
出するようにする。ステップＳ８６でのエラーはインタ
ーフェース上の障害が考えられるが、このときも受信側
のＲ５２３２制御部６０はＲＤ６１上に例えばブレーク
信号を送出するか、又はこのようなエラーが発生した事
を報知するデータを送信側に送出するようにする。

いずれにしても、上記の実施例はエラー処理が極めて単
純化され、かつ通信インターフェース上のエラー（例え
ば、ＢＣＣエラー等）に対しても従来例の如く再送手続
が不必要である事を銘記すべきである。

〈実施例の効果〉 以上説明したように本実施例によると、先ず第１にデー
タ伝送プロトコルが極めて単純化される。これは従来必
要としたデータ伝送中に発生する色々なエラーに対する
送信データ再送を送信側に促す処理ルーチンが不必要で
ある事による。従つて、たとえば全二重のデータ伝送プ
ロトコルにおいてもプロトコルの単純化の効果は極めて
大きなものがある。

第２にデータ伝送中に発生する色々なエラーに対する送
信データ再送を送信側に促す処理ルーチンが不必要とす
るために、所定時間間隔毎に常にデータを、それが前に
送信したデータであっても再送するようにした。従って
、間欠的な障害が発生しても、上記再送データにより受
信側は正常なデータを確係できる。

第３に送受信の通番管理を行うことにより、再送された
重複データをホストコンピュータ側が二重に取り込まな
いようにできる。

［発明の効果］ 以上説明したように本発明によれば、単純なプロトコル
であっても信頼性のあるデータ転送方式を提供できる。

【図面の簡単な説明】

第１図（ａ）は本発明の実施例に係るデータ転送方式に
基づいた２つのコンピュータシステムの接続を説明する
図、 第１図（ｂ）は第１図（ａ）の実施例におけるデータ転
送のタイミングチャート、 第２図はＲ５２３２デ一タ通信インターフェースの接続
図、 第３図は伝送データがバッファに格納された状態でのフ
ォーマット図 第４図は実施例の通信制御を行うためのＲ５２３２制御
部の回路図、 第５図は実施例に係る制御を実行するためのＲＡＭに格
納されているフラグ等を説明する図、第６図（ａ）、（
ｂ）は夫々送信時、受信時のバッファ管理の様子を説明
する図、 第７図（ａ）、（ｂ）及び第８図（ａ）〜（Ｃ）、そし
て第９図（ａ）〜（ｅ）は実施例の制御手順を説明する
ためのフローチャートである。 図中、 １０．２０・・・コンピュータシステム、１１．２１・
・・時間間隔監視部、１２．２２・・・送受信バッファ
、１３．２３・・・送受信部、１４．２４・・・送信通
番格納域、１５．２５・・・受信通番格納域　、　　１
６．２６・・・データ格納域、３０．３１・・・ホスト
コンピュータ、４０・・・ホストインターフェース、４
１−Ｍ　Ｐ　Ｕ、４２・　ＲＡＭ、４３−ＲＯＭ、４４
・・・タイマ、５０・・・第１送信バツフア（＃ｌ５Ｂ
）、５１・・・第２送信バツフア（＃２ＳＢ）、５２・
・・第２受信バツフア（＃ＩＲＢ）、５３・・・第１受
信バツフア（＃２ＲＢ）、５４・・・ＵＳＡＲＴ、５５
・・・ＤＭＡ、６０・・・Ｒ５２３２制御部、６１・・
・ＲＤ、６２・・・ＳＤである。 特許出願人　　　キャノン株式会社 代理人　弁理士　　　　大　塚　康ｊｊＡ　”：　舅”
−：　・　　：４ 一パ・は丈 第６図（Ｇ） 第７図（Ｇ）　　　　　　　第７図（ｂ）第８図（Ｃ） 第９図（ｂ） 第９図（Ｃ） 第９図（ｄ） 第９図（ｅ）

Claims (4)

【特許請求の範囲】
1. （１）送信側データ転送手段と受信側データ転送手段と
   の間でデータ転送を行なうデータ転送方式において、送
   信側データ転送手段は送信間隔監視手段を設け、所定時
   間間隔内に新たに転送すべきデータがない時は直前に転
   送したデータを再送する事を特徴とするデータ転送方式
   。
2. （２）送信側データ転送手段は再送データには同一通番
   を、異なる送信データには少なくとも異なる通番を割り
   付け、受信側データ転送手段は重複する通番を有するデ
   ータを複数個受信した時は１つの受信データのみを正常
   受信データとみなす事を特徴とする特許請求の範囲第１
   項記載のデータ転送方式。
3. （３）所定間隔内に送信すべきデータが複数個発生した
   とき、送信側データ転送手段は同一データを少なくとも
   ２回以上送信する事を特徴とする特許請求の範囲第１項
   記載のデータ転送方式。
4. （４）送信側データ転送手段は同一データを送信した回
   数を記録するカウンタを有し、同一データの所定回数送
   信を確保する事を特徴とする特許請求の範囲第１項に記
   載のデータ転送方式。