要約

  • 利用者はジョブをUCLAへ送り、接続を切った後で印字結果を受け取りに戻れた。計算の待ち時間と端末を接続しておく時間を分けた仕組みだった。
  • ただし、計算完了だけでは結果は届かない。RFC 599の「squish」は、出力を削除する前にネットワークの配信確認が要る理由を示している。

出力が戻る前に切断できた

バッチ処理は、依頼した人が接続を切った後も続く。NETRJSでは、遠隔ユーザーがUCLAのCampus Computing Networkへジョブを送り、いったんサインオフし、後で再接続して結果を受け取ることができた。ARPANETは入力を計算機へ運び、その出力を戻した。重要なのは接続を開くことではなく、ジョブの往復が完了することだった。

仮想端末でバッチ処理をネットワークへ

1977年のRFC 740はNETRJSを、UCLA-CCNがIBM 360 Model 91へのバッチ投入用に定義・実装した「private protocol」と呼ぶ。同じRJSは専用通信線につながる実際のカード端末も扱った。つまりこれは、ARPANETからも直接回線からも利用できる特定の計算サービスであり、ARPANET上のすべての仕事がUCLAで処理されたという意味ではない。

出力が届くまで仕事は終わらない

遠隔側はVirtual Remote Batch Terminal、すなわち仮想遠隔バッチ端末として表現された。入力用のカードリーダー、結果を返すプリンターと穿孔機、サインオンや命令、状態・エラー通知を扱う操作コンソールがある。ジョブは最大80文字のカードイメージを並べた形で送られ、JCLを含み得る。サーバーは優先度に応じてバッチシステムへ登録し、印刷物や穿孔出力を元の仮想端末へ返した。利用者は待つことも、後で戻ることもできる。

制御とデータは別々の接続を通った。操作コンソールは全二重Telnet接続、カードリーダー・プリンター・穿孔機はそれぞれ別の単方向チャネルを使う。ユーザーとサーバーの間には最大5接続を設けられた。データチャネルは使う間だけ開けばよく、三種類の装置は同時に動作できる。遠隔プロセスは対話端末ではなく、バッチ装置の仮想構成を管理した。

NETRJSは1977年に始まったわけではない。RFC 88が1971年に記述し、RFC 599が1973年に更新、RFC 740がRFC 189とRFC 599を置き換えた。1973年の更新には珍しい運用統計がある。10月にNETRJS経由で提出されたジョブは1,373件、印刷されたものが1,105件、穿孔出力は0件。カード読み取り49,400枚、印刷822,900行・18,907ページ、接続393.6時間と記録された。これはUCLAの一サービス・一か月の値で、ARPANET全体の数字ではない。平均的なジョブは入力360行（RFCの表現では「cards」）、出力745行・17.1ページで、かなり典型的とされた。

この統計だけでは出力が安全に届いたとは言えない。RFC 599は「squish」と呼ばれた問題を記す。NCPのバッファリングによる遅延のため、短い印字ファイルが遠隔ホストの最初のメッセージ受信前にRJS側で破棄される場合があった。遠隔機のクラッシュや利用者のキャンセルによって結果が失われる。修正では、NETRJSがデータ終端マークに対するRFNMを待ってから、RJSに出力破棄を指示する。処理完了と配信完了は別の境界だった。

文字コードも境界の一つだ。UCLAのIBM 360はEBCDICで動作し、遠隔側にはASCIIホストがあった。1972年、RAND、Utah、Illinoisの利用者が初期の対応表の欠陥を指摘し、UCLAは変換を修正して別の方式も追加した。1977年の規定は仮想端末にEBCDIC、ASCII-68、ASCII-63の選択肢を用意し、必要なら入力カードと印字出力を変換した。

NETRJSの意味は、利用者が計算機の前で結果を待ち続けなくても、離れた場所から計算資源を使えた点にある。仕事は優先度に沿って処理され、出力は後で回収できる一方、転送確認の前に削除すれば結果を失う。RFCが記すサインオン、カード入力、文字変換、出力回収、削除前確認は、離れた場所の人がバッチ計算を安心して頼むための条件だった。インターネットは距離を縮めただけでなく、計算を依頼し、手を離し、結果を受け取る時間の流れをつないだ。

一次資料