要約

  • RFC 1205はIBMの5250ワークステーションのデータをTelnetに載せるためのインターフェースを記した。両端はBinary、End-of-Record、Terminal-Typeに合意し、既存のIBMの透過接続方式から来たレコード形式を扱う。
  • ホストがCancel Inviteを送ると、クライアントは応答して通常の利用者データを止める。新しい読み取り指示が来て初めて入力が再開する。System Requestの例には画面保存、メニュー、復元、再招待の順番まで載る。

キーを押した後の主役はホストだった

RFC 1205で目を引くのは、端末に入力を待たせる命令だ。サーバーがCancel Inviteを送る。クライアントは同じ操作で返答し、次の読み取り命令を受けるまで通常の利用者データを送らない。キーボードは机の上にある。だがそのセッションで打った内容をいつ送れるかは、ホスト側の状態が決める。

System Requestの例を読むと、この制御が画面の動きに結び付く。利用者が対応するキーを押すと、クライアントはフラグを立てて知らせる。ホストは現在の入力の招待を取り消し、画面を保存させ、メニューを示し、その回答を受けてから元の画面を戻す。メニューへの回答にはホストが出すPut/Getの読み取り手順がある。最後のInviteで従前の作業状態に戻る。通信線の接続と、いま誰が入力できるかは、別々に管理されていた。

この仕組みは、IBMのワークステーションをインターネット上のTelnetで使いたいホストに向けて説明された。宛先までバイトが届いても、キーが画面の入力欄を埋めるのか、システム操作を求めるのかは分からない。端末の種類、画面データの区切り、ホストが読む番かどうかを両端で合わせて、ようやく一つの操作になる。RFCが公開したのは、その取り決めの通り道だった。

三つの合意で5250モードに入る

新しいTelnetオプションは作られなかった。RFCはBinary、End-of-Record、Terminal-Typeという既存の三項目について、クライアントとサーバーが少なくとも合意するよう求める。例ではホストが端末種別を問い、クライアントがIBM-5251-11と答える。続いてレコード終端と二進データの送受信を両方向で確認する。これは端末モードに必要な能力の交渉であり、利用者の本人確認手順ではない。

5250の一覧には、24行×80列の画面と27行×132列の画面、カラーと白黒、二バイト文字を扱う機種が並ぶ。どんな端末として表示するかをホストが知る必要があった。RFCには機器の属性を問い合わせるQuery Deviceの例もある。ネットワークのアドレスを見ても画面サイズは分からないからだ。

外側のTelnet交渉が済んでも、内側には5250独自のレコードがある。先頭の固定ヘッダーは六オクテット、続く可変部は当時四オクテット。その後にワークステーションのデータが置かれ、最後はIAC EORで区切られる。論理レコードの長さにはヘッダーを含める一方、終端標識は含めない。さらにIACバイトをTelnet用に二重化する前の長さを数える。ここを誤ると、次の画面指示の始点を両端が違う位置に見いだす。TCPのパケット境界では、このずれを直せない。

古いSNAの形式がTelnetの中を走る

ヘッダーはインターネット向けに新設されたものではない。IBMの5250 Display Station Pass-Throughから来ており、もとはSNA上のAS/400、System/36、System/38で使われた、とRFCは説明する。General Data Streamのレコード種別も引き継いだ。ホストが慣れた形式を残し、Telnetを運搬路として使う設計である。別のクライアントを作る人には、その古い形式を理解する仕事が残った。

RFC 1205は5250の全コマンドを一冊に収めていない。詳細はIBMの5250 Functions Reference Manualに置かれ、第5節ではその当時の版に誤りや未収録の機能があると指摘する。たとえばInsert Cursor命令の十六進値を訂正し、画面上の行・列の制約を明確にした。正しいTelnet交渉を済ませても、誤った命令値や座標を使えば画面と入力は崩れる。公開されたネットワーク側の説明と、製品固有の画面言語の知識は両方必要だった。

ここにこの資料の面白さがある。開かれた通路を使いながら、端末のふるまいはホストと5250の仕様が決める。Inviteはその支配を一語で表す。ホストが読み取りを求めたときに入力を渡す。必要になればCancel Inviteで通常の流れを止める。通信の接続が自由でも、アプリケーションの順番まで自動的に自由になるわけではない。

接続の成功と入力の順番

第4.2節ではホストとクライアントがCancel Inviteを交換し、次の読み取り命令まで通常のデータを止める。第4.3節では一時的なメニューの回答をPut/Getで受け、画面復元後のInviteで元の状態に戻す。細かな操作コードは、端末を使う人には見えない。しかし利用者が今どの画面を見て、いつ入力できるかを決めるのは、その順番だ。

RFCが示すのはインターフェースと例示である。実際の導入件数や特定サイトの逐次ログは載らない。日付付きの通信記録と画面状態を突き合わせれば、一つの現場でこの手順がどう動いたかが分かる。それでも1991年の設計上の事実は鮮明だ。IBMの端末はTelnetでホストへ向かえるよう説明されたが、文字を送る番はホストの招待で決まった。

出典