Zusammenfassung

  • RFC 1041 entwarf die einzelne Option 3270-REGIME. RFC 1576 hielt fest, dass sie nur sehr wenige Entwickler und Anbieter implementierten; die installierte Praxis verband stattdessen Terminal-Type, Binary und EOR.
  • Die drei Zustände regelten Emulation, Acht-Bit-Daten und Blockgrenzen. Sie lieferten keinen bestimmten Geräte-/LU-Namen, kein SNA BIND, keine korrelierte Verarbeitungsantwort und keine einheitliche Bedeutung für ATTN oder SYSREQ.
  • TN3270E ergänzte diese Angaben später als getrennt verhandelbare Funktionen. Die Option allein bewies weder deren Aktivierung noch Authentifizierung oder ein fachliches Ergebnis.

Der entworfene Schalter verlor gegen vorhandene Bauteile

3270-Daten unterschieden sich grundlegend vom Telnet-NVT. Sie verwendeten EBCDIC und blockorientierte Befehle. Terminalmodell, Bildschirmgröße und Erweiterungen beeinflussten die Darstellung. Für eine Verbindung über TCP mussten daher Oktettmodus, Blockende und Emulation zusammenpassen.

RFC 1041 bündelte diese Fragen 1988 in Telnet-Option 29, 3270-REGIME. Der Client sollte eine bevorzugte Liste anbieten, der Server einen gemeinsamen Regime-Namen wählen. Die Auswahl implizierte Binary und IAC EOR; eine leere Liste führte zurück zu NVT ASCII.

Besonders klar war die Übergangsordnung. Während der Verhandlung sollte der Client keine Benutzerdaten annehmen, der Server möglichst nichts senden und ausstehende Daten vor der Bestätigung abarbeiten. Server und Client wechselten ihren Parser an unterschiedlichen, genau benannten Send-/Empfangsereignissen. Puffer mussten gegebenenfalls geleert werden. Sonst konnten alte Bytes unter der neuen Grammatik erscheinen.

Doch Veröffentlichung erzeugte keine Installation. RFC 1576 berichtete 1994, nur sehr wenige Entwickler und Hersteller hätten RFC 1041 umgesetzt. Der RFC-Editor-Eintrag kennzeichnet das Dokument als Informational. Das ist keine vollständige Marktstatistik und bedeutet nicht null Implementierungen; es begründet den Blick auf das tatsächlich gemeinsame Verfahren.

Drei Verhandlungen ergaben einen de-facto-Zustand

Traditional TN3270 nutzte Telnet, Terminal-Type, Binary Transmission und End of Record. Der Server fragte nach einer Emulation, der Client nannte einen Typ. Binary erlaubte acht Bit; EOR schloss einen vollständigen 3270-Befehl mit IAC EOR.

Keine einzelne Option erklärte die Sitzung zu TN3270. Ihre Kombination tat es. Die Reihenfolge war nach RFC 1576 unerheblich. Sobald passender Typ, Binary und EOR vorlagen, konnten Blöcke fließen. Zog der Server Binary oder EOR zurück, erfüllte die Verbindung TN3270 nicht mehr; folgende Daten waren als NVT ASCII zu behandeln.

Die Wiederverwendung sparte Einführungskosten. Ihr Vertrag blieb dünn: Binary beschrieb Oktette, EOR eine Grenze, Terminal-Type eine Darstellung. Das Gateway behielt die Entscheidung, wie es die Telnet-Seite mit einer SNA- oder Nicht-SNA-Anwendung verband.

Ein Modellname war keine LU-Identität

Terminal-Type war asymmetrisch. Der Server fragte, der Client lieferte Alternativen. Der Client konnte mit seiner Antwort die Emulation wechseln. Der Server musste beim Empfang nicht sofort anders verarbeiten.

Ein 3278-Typ bezeichnete deshalb Bildschirmverhalten, nicht physische Hardware, Benutzer oder Logical Unit. Das Suffix -E deutete structured fields an; manche Server lasen zusätzlich extended attributes hinein. RFC 1576 dokumentierte diese Abweichung statt aus dem Suffix ein vollständiges Capability-Zertifikat zu machen.

In SNA besaß ein Terminal üblicherweise eine Anwendungssitzung und eine SSCP-Sitzung. Der TN3270-Client sah nur eine Telnet-Verbindung. Er konnte keinen bestimmten 3270-Gerätenamen anfordern und den vom SNA-Server verwendeten LU-Namen nicht standardisiert erfahren.

Die RFC bezeichnete die Client-IP-Adresse als das Nächstliegende zum LU-Namen. Gerade diese Formulierung trennt die Objekte: IP lokalisiert einen Netzwerkendpunkt; LU benennt eine logische Host-Ressource, auf die Anwendungen unterschiedlich reagieren konnten.

EOR quittierte Framing, nicht Verarbeitung

Ohne äußere Längenangabe brauchte ein 3270-Block EOR. IAC EOR sagte: Der Befehl ist vollständig, die Auswertung kann beginnen. Ob sie gelang, stand dort nicht.

RFC 1576 nennt den fehlenden SNA-Positiv-/Negativprozess ausdrücklich. Eine positive Antwort konnte abgeschlossene Verarbeitung anzeigen. Eine negative konnte einen ungültigen Datenstrom oder mechanischen Fehler am Client melden. Traditional TN3270 übertrug diese Quittung nicht; gesendete Daten galten als verarbeitet oder ignoriert.

TCP-Empfang, Binary-Rekonstruktion, EOR, Parserannahme, Bildschirmanzeige, Druck, Anwendungsreaktion und menschliche Wahrnehmung sind daher verschiedene Ereignisse.

NOP oder Timing Mark testeten höchstens Anwesenheit der Sitzung. NOP verlangte keine Anwendungsantwort; ein abgestürzter Client wurde möglicherweise erst durch einen TCP-Sendefehler sichtbar. Erreichbarkeit ist keine Verarbeitung.

ATTN und SYSREQ blieben lokale Übersetzungen

ATTN sollte laufende Arbeit unterbrechen. Viele Clients bildeten die Taste auf Telnet BREAK ab; der Server übersetzte weiter. Ein Nicht-SNA-Server durfte BREAK ignorieren.

SYSREQ konnte als Telnet Interrupt Process oder als 3270 Test Request erscheinen. In SNA wechselte die Funktion zwischen Anwendungs- und SSCP-Sitzung. Da das SSCP-Format nicht direkt durch traditional TN3270 passte, musste der Server es selbst behandeln, konvertieren oder die Funktion auslassen.

Tastendruck, Telnet-Kommando, Gateway-Abbildung, SNA-Ereignis und tatsächliche Unterbrechung brauchen eigene Belege.

TN3270E führte die fehlenden Belege einzeln ein

RFC 1646 und RFC 1647 beschrieben frühe Erweiterungen. RFC 2355 konsolidierte TN3270E 1998 auf dem Standards Track; der offizielle Eintrag bewahrt diese Dokumentlage.

Zuerst wurde device-type und optional resource/device-name verhandelt. Der Server konnte den zugeteilten Namen zurückgeben oder mit unbekanntem Namen, belegtem Gerät oder Typ-Namens-Konflikt ablehnen. Danach folgte die FUNCTIONS-Liste.

BIND-IMAGE meldete Aufbau und Ende der SNA-Anwendungssitzung. RESPONSES ergänzte Header, Antwortregel und Sequenznummer, damit positives oder negatives Verarbeitungsergebnis zum richtigen Block gehörte. SYSREQ und Druckfunktionen blieben separat. Auch eine leere Liste war zulässig: basic TN3270E.

Schweigen erhielt keine pauschale Bedeutung. Ein Block konnte keine Antwort, nur Fehlerantwort oder immer eine Antwort verlangen. Ohne RESPONSES war die Sequenznummer kein Beleg; ohne BIND-IMAGE gab es keine Bind-Sicht. Bei Ablehnung der Option blieb traditional TN3270 als Fallback.

RFC 2355 stellte außerdem klar, dass TN3270E keine zusätzliche Sicherheit gegenüber Telnet bot. Ein zugeteilter Gerätename war keine Berechtigung, ihn zu verwenden.

Laufender Code ist Primärbeleg, nicht Gesamtsouverän

RFC 1041 zeigt formale Klarheit ohne breite Umsetzung. Traditional TN3270 zeigt funktionierende Kompatibilität mit ausgelassenen Quittungen. TN3270E zeigt, wie diese Quittungen einzeln ergänzt werden können, ohne Altbetrieb zu verleugnen.

Heng Lus Text zur Primarität laufenden Codes richtet die Untersuchung auf das handelnde System. Die minimale gemeinsame Spezifikation mit lokalen Entscheidungen erklärt den Wert wiederverwendbarer kleiner Bausteine. Die Trennung von Realitätsschichten verhindert, dass Darstellung, Sitzung, Identität und Ergebnis in einem Symbol verschwinden. Das ist eine spätere redaktionelle Linse, keine zugeschriebene Autorenabsicht.

Drei Optionen konnten ein Terminal entstehen lassen. Terminal-Type nannte die Emulation, Binary bewahrte Bytes, EOR schloss den Block. LU, BIND, Verarbeitung, Unterbrechung und Wirkung warteten weiter auf ihre eigenen Quittungen.

Quellen