JPH0687556B2 - データ通信方法 - Google Patents

Description

【発明の詳細な説明】 A.産業上の利用分野 本発明は、データ通信に関し、より詳細には末端トラン
ザクション・プログラム間の全２重データ通信、及びそ
れらのプログラムと相互接続通信ネットワークの対話関
係に関する。本発明では、互いに通信する２つの適用業
務プログラム間の論理接続を会話と称する。それらの適
用業務プログラムは、トランザクション・プログラムと
呼ぶ。

B.従来の技術及び課題 データ通信ネットワークに接続されたトランザクション
・プログラム間の伝送機能は、通常、単信、半２重、全
２重に分類できる。単信機能は、あるトランザクション
・プログラムから別のトランザクション・プログラムへ
の単方向伝送のみをもたらすものである。半２重機能と
は、任意の時点で単信機能と同様であるが、通常はその
機能を介する会話またはデータ交換に従事するトランザ
クション・プログラム相互間の合意によって、データ流
れの方向を反転することができるものである。全２重機
能は、会話に従事するトランザクション・プログラム間
の同時２方向データ交換をもたらす。半２重及び全２重
会話の場合、その会話に係わるトランザクション・プロ
グラムは、通常、上記の相互接続伝送媒体を介して、制
御情報ならびにデータを交換する。半２重接続の性質
上、メッセージ及び制御データの順序が維持され、各会
話参加者は、順序通り適時に適切な処置を講じることが
できる。しかし、全２重会話の場合は、同時両方向伝送
が可能なため、それが常に可能であるとは限らない。

全２重環境では、送受信される受信機能と送信機能の独
立性を相関させなければならず、この独立性と信号が通
過する２つの経路の異なる遅延特性のために、状況、情
報及び応答メッセージが順序外れになった時、適用業務
プログラムにとって大きな問題が生じることがある。

C.発明の概要及び解決すべき課題 本発明は、適用業務プログラム間での１つの会話または
論理接続を利用して、全２重モードでトランザクション
適用業務プログラム間で情報及び制御データを交換する
方法を企図したものである。

本発明によれば、以前に送られたデータの確認を要求す
るトランザクション・プログラムが、その要求に対する
応答を受け取るまでそれ以上のデータの送信を阻止し、
確認要求を受け取ったトランザクション・プログラム
が、確認要求に対する応答を送るまでデータの受信を阻
止するという、ネットワークを介した１対のトランザク
ション・プログラム間での会話を通じて全２重データ交
換を行なう方法が提供される。さらに、トランザクショ
ン・プログラムが会話を終了させようと試みる時、明確
な応答が要求され、その終了に対する応答が、待ち行列
でまだ送信されていないデータの後に入って、そのデー
タをネットワークからパージする。

D.実施例 第１図は、本明細書で開示する本発明を適用できる、典
型的なデータ通信ネットワークの構成図である。このネ
ットワークは、IBMシステム・ネットワーク体系（SN
A）、さらに詳しくはLUタイプ6.2に基づいて構成され
る。紙面節約のため、以下の説明は、SNA体系に関係す
るある種の構造（物理的及び論理的）、機能及びコマン
ドを参照する。このネットワーク体系のより完全な説明
については、以下のIBM刊行物を参照のこと。

「システム・ネットワーク体系：型式及びプロトコル解
説書:LUタイプ6.2のアーキテクチャ論理（Systems Netw
ork Architecture: Format and Protocol Manual: Arch
itecture Logic for LU Type 6.2）」（SC30−3269−
２）第４版、1985年刊、インターナショナル・ビジネス
・マシーンズ・コーポレーション。

「システム・ネットワーク体系:LUタイプ6.2のトランザ
クション・プログラマ向け解説書（Systems Network Ar
chitecture: Transaction Programmer′s Reference Ma
nual for LU Type 6.2）」（GC30−3084−２）第３版、
1985年刊、インターナショナル・ビジネス・マシーンズ
・コーポレーション。

第１図で、複数のノード10、11、12、14が物理リンク1
7、18、19によって相互接続されるている。物理リンク
は、全２重リンクでも半２重リンクでも、両者の組合せ
でもよい。ノード10は、SNA体系で定義されるタイプT5
のノードであり、物理装置（PU）、１個または複数の論
理装置（LU）、システム・サービス制御点（SSCP）、１
個または複数のエンド・ユーザ・トランザクション・プ
ログラム、及び制御プログラムを含む。このノードは、
通常はIBM3090などの上位処理装置であり、ネットワー
ク、たとえば分散処理ネットワークに接続された端末ま
たは他の処理装置のためにいくつかの機能を実行するこ
とができる。

このネットワーク中のノード11は、通常はIBM3705など
の通信制御装置であり、IBMSNA体系で定義されるタイプ
T4のノードでよい。このノードは、物理装置（PU）を備
えている。ノード12と14は、共にSNA体系に基づくタイ
プT2.1のノードである。ノード12は、知能ワークステー
ションなどの端末でよく、物理装置（PU）と論理装置
（LU）を含む。ノード14は集合制御装置でよく、物理装
置（PU）と複数の論理装置（LU）を含む。15、16などい
くつかの端末を、それぞれ物理伝送媒体20と21によって
集合制御装置14に接続することができる。

PU、LU、SSCPはそれぞれ独自のネットワーク・アドレス
を有し、したがって、そのネットワーク・アドレスを使
ってメッセージが経路指定されるネットワーク・アドレ
ス可能装置（NAU）である。さらに、それぞれが物理装
置とは独立のネットワーク名を有し、SSCPから関連アド
レスが得られる。SSCPは、ネットワーク・ディレクトリ
・サービス機能を使ってネットワーク名をネットワーク
・アドレスに変換する 第２図に示すように、ユニットＡとＢなどの論理装置22
が、他のネットワーク要素を使ってネットワークを介す
るセッションを確立する。ただし、ユーザであるトラン
ザクション・プログラム（TP）23と24から見ると、これ
らの追加ネットワーク要素は存在しないように見える。

TP23やTP24などのエンド・ユーザは、以前にその間で確
立されたセッションでそれぞれLU22Aと22Bを介して互い
に通信する。この通信は、１回の会話中で行なわれる。
会話は、どとらのトランザクション・プログラムも開始
できる。この会話は、一方のエンド・ユーザ・トランザ
クション・プログラムが、それに論理的に接続されたLU
にALLOCATE動詞と適当なパラメータを発行したとき、呼
び出される。ALLOCATE動詞とそれに関連するパラメータ
は、上記に引用したLUタイプ6.2の「トランザクション
・プログラム向け解説書」で定義されている。さらに、
IBM SNA LUタイプ6.2体系におけるすべての動詞とそれ
に関連するパラメータも、この解説書に説明してある。

現在のネットワーク体系タイプLUタイプ6.2は、TP間で
半２重会話しかサポートしない。同時送受信能力は、以
前からある半２重能力を重複させるだけでは得られな
い。

全２重会話に従事する各パートナTPは、送信と受信を同
時に行なえるので、CONFIRMなどの動詞が交差すること
ができる。交差が起こるのは、両方のTPが動詞を発行
し、他方のTPが発行された動詞を受け取る前である。こ
の条件は、LU6.2の現在の半２重バージョンでは発生し
得ない。半２重バージョンでは、あるTPがCONFIRMなど
の動詞を発行すると、他方のTPがその相手方TPから発行
され受信したCONFIRMに応答するまで、会話が中断され
る（そのTPは他の動詞を発行できない）。

半２重機能を重複させただけの場合、CONFIRM動詞の交
差によって会話がデッドロック状態に陥る。たとえば、
両方のTPがCONFIRMを発行した場合、どちらもCONFIRMED
またはエラー応答で相手のCONFIRMに応答することがで
きず、両TP間の会話はデッドロック状態に陥り、それ以
上進めない。

理想を言えば、現在の体系にほとんどまたは全く影響を
及ぼさない、デッドロック問題の解決方法が最も望まし
い。というのは、半２重と全２重のどとらのタイプの会
話もサポートし、どちらを使用するかの選択をユーザに
委ねる必要があるからである。理想的には、以前からあ
る半２重会話プロセスを全くまたはほとんど変更せず
に、それを実施する必要がある。というのは、急激な変
更は大きな経済的損失を招くからである。

上記の交差問題の他に、一方または両方のTPが全２重会
話を終了するには、両TPのLU間でのセッション中にデー
タまたは情報をパージする必要がある。半２重会話で
は、このパージは、いつでも一方のTPしか送信及び終了
を行なうことができず、終了前のデータがすぐに識別で
き、問題が生じないので、問題にはならない。しかし、
全２重会話では、セッション中のデータは、パージされ
るかまたはその他の形で識別されないと、ある条件の下
では、後続のデータ・メッセージに連結されて、誤った
伝送が起こる恐れがある。

表１は、全２重会話用の有限状態マシンのテーブルであ
る。第１欄は、すべての入力、すなわちその会話で発行
された動詞（Ｓ）と受信された情報（Ｒ）を示し、第１
行は、TP−LUインターフェースでの一方のTPの会話の終
りのすべての状態を示す。各行と欄の交点に、その交点
について指示された状態の間の１つの入力の発行または
受信の結果を、記号または数字で示してある。

各記号は、下記の意味である。（／）は、特定の入力
（または動詞など）の送信または受信のうち該当する方
が不可能なことを示す。（＞）は、指示された入力の
（TPの接続されたLUへの）送信がエラー状態であり、LU
がその動詞を拒絶 することを示す。（−）は、その入力が表１に示すよう
に送信または受信されたばあいに、その会話が同じ状態
のままとなることを示す。数字（５など）は、指示され
た入力が表１に示すように送信または受信されるとき
に、その会話が移行する先の状態の番号を示す。第１欄
の文字（Ｓ）と（Ｒ）はそれぞれ送信と受信を意味し、
第１行の数字は、状態番号を示し、その会話が移行する
先の状態を示す欄と行の交点にある番号に対応する。

以下の説明では、表１に示した各入力について説明し、
またIBM SNA LUタイプ6.2体系について記載した上記に
引用した解説書の記載に対するフォーマットの変更部分
について述べる。この説明は、どちらのパートナ・トラ
ンザクション・プログラムとそれに関連するLUにも適用
されるが、２つのLUは、上記に引用した解説書に詳しく
記載されている以前からあるLUタイプ6.2の手順に従っ
て、それらの間で少なくとも１回セッションを確立した
ことがあると仮定する。さらに、会話がとり得る17の状
態をそれぞれ識別し、説明する。

２つのトランザクション・プログラムの間で会話が確立
される前には、その会話は、リセット状態にある。この
状態は、表１では状態（１）として識別されている。こ
の状態のとき、トランザクション・プログラムは、その
LUにALLOCATE動詞を送って、全２重（FDX）会話を開始
することができる。ALLOCATE動詞に関する唯一の修正
は、この動詞の以前からある会話タイプ・フィールドに
加えられるFDX_BASIC_CONVERSATIONの値として新しい値
を使用することである。

以下の説明では、構内LUと遠隔LUという言葉を使用す
る。構内LUとは、動詞を送るまたは発行するTPに直接接
続された、あるいはそのTPにサービスするLUである。遠
隔LUとは、他方のTPに直接接続された、あるいはそのTP
にサービスするLUである。トランザクション・プログラ
ムがALLOCATE動詞を送ると、構内LUは、機能管理ヘッダ
・メッセージ（FMH−５（接続）、上記解説書で定義さ
れている）を生成して遠隔LUに送る。FMH−５（接続）
に加える必要のある唯一の変更は、このメッセージ中の
以前からある会話タイプ・フィールドに新しい16進値
Ｘ′D2′を加えることである。このメッセージを受け取
ったLUは、遠隔トランザクション・プログラムと接続し
て、その会話を形成する。

前記のように、会話の開始前はどちらのトランザクショ
ン・プログラムもリセット状態にあった。ALLOCATE動詞
を発行したTPは、ALLOCATE動詞が送られるとき、状態１
から状態（２）SEND_RECEIVE_RESTRICTED（SEND RCV RS
TD）に移り、遠隔の相手方TPは、接続される（表１に入
力“Ｒ、ATTACH"で示す）とき、状態（３）SEND_RECEIV
E_PRIVILEGED（SEND RCV PRVG）に移る。表１に示すよ
うに、状態２にあるTPはいくつかの入力を送信または受
信することができる。SEND−DATAなどそれらの入力のう
ちのあるものは、記号（−）で示されているように、状
態変化を起こさない。CONFIRMなど他のものは、プログ
ラムを別の状態に変える（CONFIRMの場合は、TPは状態
５に変わる）。発行しない入力は記号（／）で示し、エ
ラー状態を示すが故に拒絶される入力は記号（＞）で示
してある。

話を簡単にするため、残りの入力及び状態について個々
に述べ、以前からあるSNA LUタイプ6.2との形及び機能
の違いについて説明する。

上記のALLOCATE入力とATTACH入力の他に、表１には28個
の入力が列挙してあり、それらについて次に述べる。

SEND_DATA入力は、LU6.2内の以前からある動詞であり、
RECEIVE_ERROR、PROGRAM_RECEIVE_ERROR、SVC_RECEIVE_
ERROR、DEALLOCATE_NORMALの追加の４つの戻りコードを
供給する場合以外は変更されない。これらのエラー戻り
コードは新しいものであり、構内LUが遠隔LUから−RS
P、FMH−７（Ｘ′08890002′）、FMH−７（Ｘ′0889010
2′）または条件付きブラケット終了（CEB）メッセージ
を受け取った結果生成する。遠隔LUは、このアーキテク
チャ中で定義されるエラーの発生源に応じて、これらの
流れを作成する。割振り解除戻りコードは、相手方TPが
指定されたタイプ（FLUSH）のDEALLOCATE動詞を発行し
た結果、生成される。これは以前からある戻りコードで
あり、半２重会話に対して発行されるとき、データ送信
時に戻されない。この４つの戻りコード（RC）は、表１
に示すFSM中に入力として列挙してあり、後で明らかに
なるように、異なるシーケンスによって生成できる。

FLUSH入力は以前からある動詞であり、変更されない。T
Pによって発行されたFLUSHがない場合、LUは、TPから送
られたデータをそのバァファが満杯になるまで緩衝記憶
する。バァファが満杯になると、その内容が会話を通じ
て遠隔LUに送られる。この遅延は、TPが構内LUにFLUSH
動詞を発行することによって克服できる。このことは、
データ・ベースや適用業務プログラムへの短い問合せメ
ッセージなど、ある状況では好都合である。というのは
短いメッセージだとバァファが満杯にならないからであ
る。

CONFIRM入力は、TPによって発行される以前からある動
詞であり、戻りコードとして、上記の３つの新しいエラ
ー戻りコード、すなわちRECEIVE_ERROR、PROGRAM_RECEI
VE_ERROR、SVC_RECEIVE_ERRORを受け取ることができ
る。さらに、LUはただちに制御権をTPに戻し、OK戻りコ
ードは、CONFIRMが相手方TPに送られたことを示すだけ
である。CONFIRM要求に対する相手方TPの回答は、後続
のRECEIVE_＊動詞、すなわちRECEIVE_AND_WAITまたはRE
CEIVE_IMMEDIATEがTPによって発行されたとき、TPにパ
スされる。

SEND_ERROR_SENDとSEND_ERROR_RECEIVEは、以前からあ
る動詞SEND_ERRORのある形であり、DIRECTIONと呼ばれ
るエラーが発生した方向（SENDまたはRECEIVE）を示す
新しいパラメータが追加されている。たとえばSEND_ERR
OR_SENDは、そのTPが相手方TPに送ったデータ中にエラ
ーを検出したことを示す。

POST_ON_RECEIPT入力は、TPによって発行される以前か
らある動詞であり、変更されない。TEST入力もTPによっ
て発行される以前からある動詞であり、上記の同じ３つ
の新しいエラー戻りコードを与えられている。RECEIVE_
IMMEDIATE入力は、TPによって発行される以前からある
動詞である。上記の３つの新しいエラー戻りコードの他
に、新しい値“CONFIRMED"が、以前からあるWHAT_RECEI
VEDパラメータに追加されている。

RECEIVE_AND_WAIT入力もTPによって発行される以前から
ある動詞であり、上記の３つの新しいエラー戻りコード
を備えており、WHAT_RECEIVEDパラメータは新しい値“C
ONFIRMED"を与えられている。REQUEST_TO_SEND入力はTP
によって発行される以前からある動詞であり、全２重で
はトランザクション・プログラムによって指定された何
らかの意味をもつことももたないこともある。

DATA_INDICATOR入力、CONFIRM_INDICATOR入力、及びCON
FIRM_DEALLOC_IND入力は、それぞれDATA、CONFIRM、CON
FIRM_DEALLOCATEの以前からあるWHAT_RECEIVED値であ
り、RECEIVE_＊動詞が発行されたとき、TPに戻される。
CONFIRMED_INDICATOR入力はCONFIRMEDの新しいWHAT_REC
EIVED値であり、RECEIVE_＊動詞が発行されたとき、TP
に戻される。

CONFIRMED入力は、TPによって発行される以前からある
動詞である。プロトコルの唯一の変更は、確認要求を受
け取ったTPが、当該の場合、ただちにCONFIRMEDで回答
する必要がないことである。RECEIVED_ERROR_RC、PROGR
AM_ERROR_RC、SERVICE_ERROR_RCは、上述した３つの新
しいエラー戻りコードであり、それぞれTPが動詞を発行
したときにTPに戻され、エラーの性質を示す。

DEALLOC_NORMAL_RC、DEALLOC_ABEND_RC、RESOURCE_FAIL
URE_RC、ALLOCATION_ERROR_RCは、それぞれDEALLOCATE_
NORMAL、DEALLOCATE_ABEND_＊、RESOURCE_FAILURE_＊、
ALLOCATION_ERROR＊の以前からある戻りコード値であ
り、TPが動詞を発行したとき、適宜TPに戻される。

DEALLOCATE_FLUSH入力は、TPによって発行されるTYPE
（FLUSH）の以前からあるDEALLOCATE動詞である。この
動詞の結果流れる条件付きブラケット終了（CED）は，
要求された一定の応答、及び以前からあるプロトコルと
は異なる必要な待機応答（RQD＊、QRI）で流れる。

DEALLOCATE_CONFIRM入力は、TPによって発行される以前
からある動詞（TYPE＝CONFIRM）である。SEND_DATA入力
に対する上記の３つの新しいエラー戻りコードが、この
動詞にも適用される。LUはただちに制御権を戻し、戻さ
れたOKは、CONFIRM_DEALLOCATE要求が相手方TPに送られ
たことを示すだけなので、この動詞の処理は修正されて
いる。確認要求に対する相手方TPの回答は、後続のRECE
IVE_＊動詞の発行時に開始側TPにパスされる。さらに、
この動詞の結果流れるCEBは、RQD＊、QRIを流す。

DEALLOCATE_ABEND入力は、以前からあるDEALLOCATE動詞
（TYPE＝ABEND_＊）であり、TPによって発行される。こ
の動詞の結果流れるCEBは、RQD＊、QRIを流す。DEALLOC
ATE_LOCAL（TYPE＝LOCAL）入力とGET ATTRIBUTES入力
は、TPによって発行される以前からある動詞である。SI
GNAL（END_PURGING）入力は、動詞でも行流れでもな
い。これは、END_CHAIL標識が受け取られ、到着データ
のパージが終了できることを示す、FSMへの入力であ
る。

ここで17個のFSM状態について説明する。これらの状態
は、状態１と17を除き、TPから見て会話が占めている状
態を表し、現状態に応じて、表１に示すようなTPが取り
得る処置（すなわち入力）、及びその処置を取った結果
（すなわち状態遷移）を規定する。

TPが状態1RESETのときは、会話は存在しない。しかし、
会話が開始できるのは、この状態からTPがALLOCATE動詞
を発行したときだけである。状態17END CONVERSATION
（END CONV）に入るのは、会話の終りである。これは、
表１に数字17で示したいくつかの状況のもとで起こる。
また会話は終了でき、TPは会話の存在しない状態１に直
接移る。こうした遷移は、表１に数字（１）で示してあ
る。

状態２のSEND RECEIVE RESTRICTED（SEND RCV RSTD）状
態のとき、会話は送信または受信制限状態にある。この
状態のトランザクション・プログラムは、その会話に対
して送信及び受信に関係する動詞を発行することができ
る。この状態にある会話に課される主な制限は、SEND_E
RROR（DIRECTION＝RECEIVE）をこのときトランザクショ
ン・プログラムがその会話に対して発行できないことで
ある。これは、トランザクション・プログラムが、SEND
_ERRORの結果生成される否定応答（−RSP）が送られる
先の連鎖を受け取っていないためである。表１には、会
話時に発行できる許容されたSEND動詞と、受信標識また
は受け取ることができる戻りコードが示されている。さ
らに、この表には、状態遷移が数字で示してある。たと
えば、このときトランザクション・プログラムがCONFIR
Mを発行した場合、FSMは状態５に変わる。

状態３のSEND RECEIVE PRIVILEGED（SEND RCV PRVG）の
とき、会話は特権送信状態または特権受信状態にある。
この状態は、SEND RCV PSTD状態で許される他の動詞に
加えてSEND_ERROR（DIRECTION＝RECEIVE）も許される点
以外は、SEND RCV RSTD状態に類似している。表１のSEN
D_ERROR_RECEIVE入力の所にこのことが示されている。
会話が状態２のときにこの入力が供給された場合、エラ
ー状態が存在するが、状態３のときは、この入力は受け
入れられ、会話は状態４に遷移する。

状態４のSEND RECEIVE PURGE（SEND RCV PURGE）状態の
とき、トランザクション・プログラムはSEND_ERROR（DI
RECTION＝RECEIVE）を発行済みであり、トランザクショ
ン・プログラムのLUがすべての到着データをパージす
る。到着データのパージは、連鎖終了（EC）を運ぶ流れ
を受け取ったとき終了する。

状態５のSENT CONFIRM RESTRICTED（SENT SFRM RSTD）
状態のとき、トランザクション・プログラムは、すでに
相手方TPに確認要求を送っており、相手方TPの回答を待
っている。状態５では、TPが確認要求を送った他のすべ
ての状態（状態６、７、９、11〜16）と同様に、TPは、
それが送った要求に対する相手方TPの応答を受け取るま
で、データの送信を許されない。その回答を受け取った
とき、会話は、通常はSEND RCV RSTD状態に戻る。この
ことは、表１の状態５の下の欄を見れば確認できる。プ
ログラムが確認標識を受け取ると、会話は状態２に戻
る。

また、TPがRECEIVE_ERROR_RC戻りコードを受け取った場
合も、会話は状態２に戻る。他の入力及びその会話が移
る先の他の状態は、状態５に関連する欄に示してある。

状態６のSENT CONFIRM PRIVILEGED（SENT CFRM PRVG）
状態のとき、トランザクション・プログラムはすでに相
手方TPにCONFIRM要求を送っており、相手方TPの回答を
待っている。回答を受け取ると、会話はSEND RCV PRVG
状態３に戻る。このことは状態６に関連する欄に示して
あり、CONFIRMED_INDICATORまたはRECEIVE_ERROR_RC戻
りコードを受け取ったときに起こる。

状態７のSENT CONFIRM PURGE（SENT CFRM PURGE）状態
のとき、トランザクション・プログラムはすでに相手方
TPにCONFIRM要求を送っており、相手方TPの回答を待っ
ている。回答を受け取ると、会話はSEND RCV PURGE状態
４に戻る。関連する欄に示してあるように、このことが
起こるのは、トランザクション・プログラムがCONFIRM_
INDICATORまたはRECEIVE_ERROR_RC戻りコードを受け取
るときである。

状態８のRECEIVED CONFIRM（RCVD CFRM）状態では、ト
ランザクション・プログラムはすでに相手方TPから確認
要求（CONFIRM_INDICATOR）を受け取っているが、その
要求にまだ回答していない。確認要求を受け取るトラン
ザクション・プログラムに関する限り、トランザクショ
ン・プログラムがその回答に応答するか、またはRCVD_C
FRM状態に関連する欄に示す他の何らかの処置を講じる
まで、会話はこの状態に留まる。さらに、状態８では、
TPがすでに確認要求を受け取った他のすべての状態（状
態９〜13）と同様に、TPは、受信した要求に応答するま
で、情報を受け取ることを許されない。

状態９のCONFIRM CROSSINGWITH CONFIRM（CFRM XINGCFR
M）のとき、トランザクション・プログラムはすでに確
認要求（CONFIRM及びCONFIRM_INDICATOR）を送りかつ受
け取っており、受け取った要求にまだ応答していない。
SEND_ERROR_RECEIVEとCONFIRMEDのうち、どちらか受け
取った確認に関してそのとき存在する条件のもとで適切
な方を送るとき、会話は状態８に移る。

状態10のRECEIVED CONFIRMED DEALLOCATE（RCVD CFRM D
EAL）状態のとき、トランザクション・プログラムはす
でに割振り解除確認要求（CONFIRM_DEALLOC_IND）を送
っており、まだ回答していない。DEALLOCATE_FLUSHまた
はDEALLOCATE_ABENDを送るとき、会話は状態1RESETに移
る。SEND_ERROR_RECEIVEを送るとき、会話は状態２に移
る。CONFIRMEDを送ると、会話は状態17に移って終了
し、CONFIRMまたはDEALLOCATE_CONFIRMを送るとき、そ
れぞれ状態11及び13にただちに移る。

状態11のCONFIRM CROSSINGWITH CONFIRM DEALLOCATE（C
FRM XING CFRM DEAL）状態のとき、トランザクション・
プログラムはすでに確認要求（CONFIRM）を送り、割振
り解除確認要求（CONFIRM_DEALLOC_IND）を受け取って
いる。SEND_ERROR_RECEIVEを送るとき、その会話は状態
５に移ることができ、CONFIRMEDを送ると状態17に移
る。

状態12のCONFIRM DEALLOCATE CROSSING WITH CONFIRM
（CFRM DEAL XING CFRM）状態のとき、トランザクショ
ン・プログラムはすでに割振り解除確認要求（DEALLOCA
TE_CONFIRM）を送っており、確認要求（CONFIRM_INDICA
TOR）を受け取っている。この状態のときは、下記の状
態14への遷移だけが許される。この遷移は、トランザク
ション・プログラムがSEND_ERROR_RECEIVEまたはCONFIR
MEDを送るときに起こる。

状態13のCONFIRM DEALLOCATE CROSSING WITH CONFIRM D
EALLOCATE（CFRM DEAL XING CFRM DEAL）状態のとき、
トランザクション・プログラムはすでに割振り解除要求
（DEALLOCATE_CONFIRMとCONFIRM_DEALLOC_IND）をそれ
ぞれ送り、かつ受け取っている。その会話は、CONFIRME
D_INDICATORを受け取ったとき状態1RESETに戻ることが
でき、SEND_ERROR_RECEIVEを送るとき状態14に戻る。

状態14のSENT CONFIRM DEALLOCATE RESTRICTED（SENT C
FRM DEAL RSTD）状態のとき、トランザクション・プロ
グラムはすでに割振り解除確認要求（DEALLOCATE_CONFI
RM）を相手方TPに送り、相手方TPの回答を待っている。
相手方TPがその要求に否定の回答をした場合、会話はSE
ND_RCV_RSTD状態２に戻る。これは、トランザクション
・プログラムがRECEIVE_ERROR_RC戻りコードを受け取っ
たとき起きる。その会話は、CONFIRMED_INDICATORを受
け取ったとき、RESET状態１に戻る。各受信入力につい
ての他の状態遷移は、状態14の関連する欄に示してあ
る。

状態15のSENT CONFIRM DEALLOCATE PRIVILEGED（SENT C
FRM DEAL PRVG）状態のとき、トランザクション・プロ
グラムはすでに割振り解除要求（DEALLOCATE_CONFIRM）
を相手方TPに送り、相手方TPの回答を待っている。相手
方TPがこの要求に否定の回答をした場合、会話はSEND R
CV PRVG状態３に戻る。これは、状態15に関連する欄にR
ECEIVE_ERROR_RC戻りコードの受信で示される。また、C
ONFIRMED_INDICATORを受け取ると、会話はRESET状態１
に移る。状態15からのその他の遷移は、状態15に関連す
る欄に示してあり、指示した入力を送ったまたは受け取
ったときの状態12、13、14、17への遷移がそれに含まれ
る。

状態16のSENT CONFIRM DEALLOCATE PURGE（SENT CFRM D
EAL PURGE）状態のとき、トランザクション・プログラ
ムはすでに相手方TPに割振り解除確認要求（DEALLOCATE
_CONFIRM）を送り、相手方TPの回答を待っている。相手
方TPがその要求に否定の回答をした場合、会話はSEND R
CV PURGE状態４に戻る。これは、RECEIVE_ERROR_RC戻り
コードの受信によって示される。さらに、CONFIRMED_IN
DICATORを受け取ると、その会話はRESET状態１に移り、
指示された入力を受け取ったときの他の遷移は状態６に
関連する欄に示してある。

本発明をその好ましい実施例に関して具体的に図示し説
明してきたが、当業者なら理解できるように、本発明の
精神及び範囲から逸脱することなく、本発明に様々な形
状及び細部の変更を加えることが可能である。

E.発明の効果 以上のように本発明の通信方法によれば前２重モードで
トランザクション・プログラム間での情報及び制御デー
タの交換が可能となる。

【図面の簡単な説明】

第１図は、この新規な全２重通信方法で利用できるデー
タ通信ネットワークの構成図である。 第２図は、第１図に示したネットワークの単純化した構
成図である。 10……上位処理装置、11……通信制御装置、12、15、16
……端末、14……集合制御装置、17、18、19……物理ノ
ード、20、21……物理伝送媒体、22……論理装置（L
U）、23、24……トランザクション・プログラム（T
P）。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 マーク・ポゼフスキイ アメリカ合衆国ノース・カロライナ州チヤ ペル・ヒル、タツドレイ・ドライブ2100番 地 (72)発明者 ジョン・フラーズイ・ウイルダー アメリカ合衆国ノース・カロライナ州ラレ イ、ラボツク・ドライブ3604番地 (56)参考文献 特開 昭58−116827（ＪＰ，Ａ) 特開 昭54−5303（ＪＰ，Ａ)

Claims (1)

【特許請求の範囲】
1. 【請求項１】データ及び制御を表す電子信号がそれを介
   して両方のトランザクション・プログラムの制御下で交
   換される少なくとも１回の通信セッションによって、そ
   れぞれ第１及び第２のトランザクション・プログラムに
   接続されまた相互に接続された、少なくとも第１及び第
   ２の論理装置を含む通信ネットワークを介して、第１と
   第２のトランザクション・プログラムの間で全２重会話
   を動作させる方法であって、 （ａ）上記第１のトランザクション・プログラムで、上
   記第２のトランザクション・プログラムとの会話を開始
   するための第１の入力を、接続された第１の論理装置に
   発行するステップと、 （ｂ）上記第１の論理装置が、上記第１の入力に応答し
   て第１のメッセージを生成して上記第２の論理装置に送
   信するステップと、 （ｃ）上記第２の論理装置が、上記第１のメッセージを
   受け取り、開始を要求された会話の確立をするために接
   続を指示する第２の入力を生成して、接続された第２の
   トランザクション・プログラムに送るステップと、 （ｄ）上記トランザクション・プログラムのいずれか一
   方または両方で、必要に応じてデータを送信または受信
   しあるいはその両方を行うために、１つまたは複数の入
   力を発行するステップと、 （ｅ）必要に応じて上記トランザクション・プログラム
   の一方で、以前に送られたデータの確認を要求する第３
   の入力を生成して、接続された論理装置に送り、その後
   は相手方のトランザクション・プログラムからの確認を
   示す応答を接続された論理装置から受け取るまで、デー
   タの送信を阻止するステップと、 （ｆ）一方または両方のトランザクション・プログラム
   で、会話の終了を示す入力をその接続された論理装置に
   送るステップと、 （ｇ）上記接続された論理装置において、会話の終了を
   示す上記入力を受信し、会話の終了を示す第２の独自の
   メッセージを生成して他のトランザクション・プログラ
   ムに接続された論理装置に送り、上記他のトランザクシ
   ョン・プログラムからの送られていないいかなるデータ
   に後続する列をなす応答を要求し、事前に送られていな
   かった終了された会話に関するいかなるデータがたとえ
   あっても、上記トランザクション・プログラムの相互接
   続ネットワークからパージされるステップと を有するデータ通信方法。