Zusammenfassung

  • RFC 1205 beschrieb eine Telnet-Schnittstelle für den Datenstrom einer IBM-5250-Workstation. Client und Server mussten Binary, End-of-Record und Terminal-Type vereinbaren und danach ein aus IBMs älterem Pass-Through-Verfahren stammendes Satzformat verstehen.
  • Im Beispiel zu Cancel Invite stoppt der Client nach der Bestätigung gewöhnliche Nutzerdaten, bis der Host einen neuen Lesebefehl sendet. Ein System Request zeigt die vollständige Unterbrechung: Bildschirm sichern, Menü anzeigen, Antwort entgegennehmen, Bildschirm wiederherstellen und Eingabe erneut einladen.

Der Host vergab das Rederecht

Ein verbundenes Terminal hatte bei IBM nicht ständig das Recht, seine Tastaturdaten zu senden. RFC 1205 beschreibt den Umschaltpunkt genau: Der Server schickt Cancel Invite, der Client antwortet mit derselben Operation und hält Nutzerdaten zurück. Erst ein neuer Lesebefehl lädt die Workstation wieder ein. Das Kabel bleibt angeschlossen. Der Host bestimmt innerhalb der Anwendung, wann die normale Eingabe wieder an der Reihe ist.

Im System-Request-Beispiel ist der Ablauf länger. Ein Tastendruck setzt auf dem Client ein entsprechendes Flag. Der Host widerruft die laufende Einladung, lässt den Bildschirminhalt sichern und zeigt ein Systemmenü. Für dessen Antwort folgt ein vom Host veranlasster Put/Get-Schritt. Anschließend stellt er den alten Bildschirm wieder her und schickt ein Invite, das die vorherige Arbeit fortsetzt. Die Eingabe in das Menü ist also ein eigener, eng umrissener Leseschritt des Hosts; sie läuft nicht einfach als Fortsetzung der alten Dateneingabe weiter.

P. Chmielewski schrieb dieses Dokument für Implementierer, die einen 5250-Client für Internet-Hosts bauen wollten. Ein gewöhnlicher Telnet-Datenstrom konnte die Bytes liefern. Ob ein Byte ein Zeichen im Eingabefeld, eine Sondertaste oder Teil einer Bildschirmoperation war, entschied die 5250-Sprache. Die Verbindung zum Rechner war nur der Anfang eines funktionsfähigen Terminals.

Drei bekannte Optionen, viele unbekannte Details

RFC 1205 erfand keine weitere Telnet-Option. Beide Seiten mussten mindestens Binary, End-of-Record und Terminal-Type aushandeln. Der beispielhafte Server fragt nach dem Terminaltyp, worauf der Client IBM-5251-11 meldet. Danach werden in beide Richtungen Satzenden und binäre Übertragung vereinbart. Diese Antworten geben dem Datenstrom Rahmen und Form. Sie ersetzen weder die Bildschirmbefehle noch die Entscheidung des Hosts über die nächste Eingabe.

Die Typenliste zeigt, wie unterschiedlich 5250-Geräte sein konnten: 24 Zeilen mit 80 Spalten oder 27 mit 132, farbige und monochrome Varianten, teils mit Doppelbyte-Zeichensatz. Der Server brauchte diese Auskunft, um seinen Bildschirm passend aufzubauen. Ein zusätzliches Query-Device-Beispiel lässt den Host Geräteeigenschaften erfragen und den Client antworten. Aus der Netzadresse allein lässt sich kein Bildschirmformat ablesen.

Nach der Telnet-Verhandlung folgen logische 5250-Sätze. Vor dem Workstation-Datenstrom liegen sechs feste Oktette und ein variabler Teil, der damals vier Oktette umfasste. Die Längenangabe zählt den Kopf mit, wird vor einer Verdoppelung von IAC-Bytes durch Telnet berechnet und lässt den abschließenden Marker IAC EOR aus. Wer den Zähler nach der Umwandlung berechnet, kann den Anfang des nächsten Bildschirmbefehls falsch finden. TCP-Segmente liefern dafür keine verlässliche Ersatzgrenze.

Die ältere SNA-Hülle fuhr mit

Der Kopf stammte aus 5250 Display Station Pass-Through, einem Verfahren auf SNA für AS/400, System/36 und System/38. Auch der Typ General Data Stream blieb erhalten. Der Host konnte mit einer vertrauten Darstellung arbeiten, während die Daten nun über Telnet transportiert wurden. Für Entwickler anderer Clients bedeutete Wiederverwendung jedoch Nacharbeit: Sie mussten die alte Hülle und den darin liegenden Bildschirmstrom korrekt auswerten.

Das RFC verweist für sämtliche 5250-Befehle auf IBMs 5250 Functions Reference Manual. In Abschnitt 5 berichtigt es Fehler der damals vorliegenden Ausgabe und ergänzt noch fehlende Funktionen. Unter anderem korrigiert es den hexadezimalen Wert für Insert Cursor und klärt Grenzen von Zeilen- und Spaltenadressen. Das sind Fehler, die ein Mensch am Bildschirm bemerkt, obwohl alle Telnet-Optionen längst auf „ja“ stehen. Ein falsch positionierter Cursor wird nicht durch eine erfolgreiche Paketübertragung repariert.

Die veröffentlichte Netzschnittstelle half, einen weiteren Client zu entwickeln. Die vollständige Bedeutung der Bildschirmbefehle lag weiterhin im IBM-Handbuch. So blieb der Host Herr der Eingabereihenfolge, während Telnet die Verbindung für andere Rechner erreichbar machte. Die technische Öffnung hatte eine konkrete Grenze: Transport und Terminalverhalten kamen aus verschiedenen Verträgen.

Der Fehler, den die Verbindung nicht verrät

Ein Client konnte sämtliche Telnet-Optionen korrekt beantworten und trotzdem unbrauchbar sein. Die Länge eines 5250-Satzes wurde vor Telnet-Escaping berechnet; die Bildschirmbefehle mussten nach dem IBM-Handbuch gelesen werden; die Freigabe gewöhnlicher Eingaben hing vom aktuellen Host-Befehl ab. Ein grünes Licht für die Verbindung sagte über diese drei Prüfungen nichts aus. Das machte Kompatibilität zu einer Eigenschaft des ganzen Dialogs, nicht des Verbindungsaufbaus.

RFC 1205 enthält dafür Beispiele und Korrekturen am Handbuch, aber kein datiertes Protokoll eines produktiven Einsatzes. Ein Mitschnitt zusammen mit dem sichtbaren Bildschirmzustand könnte zeigen, ob ein konkreter Client diese drei Prüfungen bestand. Bis dahin liegt die historische Aussage im veröffentlichten Entwurf: Die Schnittstelle brachte 5250 über Telnet, und die Arbeit am Bildschirm verlangte weiterhin genaue Kenntnis des alten Systems.

Quelle