Zusammenfassung

  • NETRJS ließ einen entfernten Rechner als virtuelles Stapelterminal für UCLAs IBM 360/91 auftreten.
  • Konsole, Karteneingabe und Druckausgabe liefen über getrennte Kanäle; die RFCs dokumentieren auch Zeichenkonvertierung und Zustellfehler.

Die Ausgabe kam nach der Abmeldung

Ein Stapelauftrag konnte fertig werden, obwohl der Nutzer längst nicht mehr verbunden war. Mit NETRJS schickte ein entfernter Nutzer den Auftrag an das Campus Computing Network der UCLA, meldete sich ab und konnte später das Ergebnis abholen. Das ARPANET transportierte die Eingabe zum Rechner und dessen Ausgabe zurück. Entscheidend war der vollständige Hin- und Rückweg des Auftrags, nicht allein der Verbindungsaufbau.

Das virtuelle Terminal brachte Stapelarbeit ins Netz

RFC 740 von 1977 bezeichnet NETRJS als privates Protokoll, das UCLA-CCN für Stapelaufträge an einen IBM 360 Model 91 definiert und implementiert hatte. Derselbe RJS-Dienst bediente auch reale Karten-Terminals über direkte Kommunikationsleitungen. Es war ein bestimmter Rechendienst mit mehreren Zugangswegen; daraus folgt nicht, dass alle ARPANET-Aufträge an der UCLA liefen.

Erst mit der Ausgabe war der Auftrag beendet

Der entfernte Endpunkt wurde als Virtual Remote Batch Terminal modelliert: ein Kartenleser für eingehende Aufträge, Drucker und Stanzer für Ergebnisse sowie eine Bedienkonsole für Anmeldung, Befehle, Status und Fehlermeldungen. Der Auftrag kam als Folge von Kartenbildern mit höchstens 80 Zeichen, einschließlich Job Control Language. Der Server reihte ihn nach Priorität in das Stapelsystem ein und schickte Druck- oder Stanzdaten an dasselbe virtuelle Terminal zurück. Der Nutzer konnte warten oder später wiederkommen.

Steuerung und Daten waren getrennt. Die Bedienkonsole nutzte eine Vollduplex-Telnet-Verbindung; Kartenleser, Drucker und Stanzer hatten je einen eigenen Simplex-Kanal. Bis zu fünf Verbindungen zwischen Nutzer- und Serverprozess waren vorgesehen. Datenkanäle mussten nur während der Nutzung offen sein, und die drei Gerätearten konnten gleichzeitig arbeiten. Der entfernte Rechner steuerte so ein Modell virtueller Stapelgeräte statt einer interaktiven Terminalsitzung.

NETRJS begann vor dem RFC von 1977. RFC 88 beschrieb es 1971, RFC 599 aktualisierte es 1973, RFC 740 löste RFC 189 und RFC 599 ab. Die Aktualisierung von 1973 enthält seltene Betriebsdaten: Im Oktober reichte UCLA-CCN über NETRJS 1.373 Aufträge ein; 1.105 wurden gedruckt, keiner gestanzt. Erfasst wurden 49.400 gelesene Karten, 822.900 gedruckte Zeilen, 18.907 Seiten und 393,6 Verbindungsstunden. Das sind Werte eines Dienstes in einem Monat, keine ARPANET-weite Statistik. Als ziemlich typisch galt ein Auftrag mit 360 Eingabezeilen („cards“) und 745 Ausgabezeilen auf 17,1 Seiten.

Die Summen bewiesen nicht, dass ein Ergebnis angekommen war. RFC 599 beschreibt einen Fehler namens „squish“: Durch NCP-Pufferung konnte der Stapelrechner eine kurze Druckdatei löschen, bevor die erste Nachricht den entfernten Rechner erreichte. Ein Absturz oder Abbruch auf der Gegenseite konnte das Ergebnis unwiederbringlich machen. Die Korrektur ließ NETRJS die RFNM-Bestätigung des Datenendes abwarten, bevor RJS die Ausgabe verwarf. Ein Auftrag musste also zwei Grenzen überschreiten: die Berechnung und die Zustellung.

Auch Zeichensätze bildeten eine Grenze. UCLAs IBM 360 verarbeitete EBCDIC; einige entfernte Nutzerprozesse verwendeten ASCII. 1972 meldeten Nutzer an RAND, Utah und Illinois Mängel der ursprünglichen Zuordnung. UCLA änderte die Tabelle und ergänzte eine weitere. RFC 740 ließ das virtuelle Terminal EBCDIC, ASCII-68 oder ASCII-63 wählen und konvertierte Eingabekarten sowie Druckausgaben bei Bedarf.

NETRJS zeigt ein Internet, das geplante Arbeit transportieren konnte, nicht nur Live-Gespräche. Der Nutzer sandte einen strukturierten Auftrag, der Dienst bestimmte die Ausführung, getrennte Kanäle lieferten das Ergebnis. Die RFCs beschreiben den konkreten Vertrag: Anmeldung, Karteneingabe, Ausgabeabruf, Zeichensatzkompatibilität und Bestätigung vor dem Löschen. Das Netz machte den Rechner erreichbar; der Dienst machte den gesamten Arbeitsgang nutzbar.

Primärquellen