SNA - noch immer nur beschränkt tauglich

09.02.1979

WALTHAM - Ketzerisch stellte die IDC (International Data Corp.) ihrer jüngsten Untersuchung über SNA-Anwender die Frage voran: "Ist SNA ein Flop?" IDC begründet seine kritische Einstellung gegenüber IBMs Systems Network Architecture mit den nach vier Jahren körperlicher (das Konzept stammt von Anfang 1970) SNA-Time immer noch mickrigen Implementierungs-Zahlen: "Weniger als 650 Sitze im SNA-Waggon sind besetzt."

Dabei ist der SNA-Gedanke zunächst sehr einleuchtend: Der Anwender muß dadurch ein DÜ-Netzwerk nicht mehr in physikalischen Komponenten denken, sondern kann es als "Logisches Netzwerk" betrachten. Durch die Terminalorientierung werden in einer hierarchischen Netzstruktur Distributed Processing-Funktionen erreicht, die (SDLC-Eigenart) zwar keine sehr schnelle Nachrichtenübertragung erlauben, aber für große Anlagen exzellente Fernverarbeitung ermöglichen.

Welche Probleme haben nun den Siegeszug von SNA gebremst? Sicherlich gleich mal die Preise, zumal die SNA-Terminals bei ihrem Announcement (3767, 3774) erheblich teurer als die Vorgänger-Terminals (2740-2, 2780 und 3780) waren.

Schnell stellte sich aber auch heraus daß SNA für kleinere und mittlere Anwender (unter 370-125-2) "nicht die effizienteste und wirtschaftlichste Lösung darstellt", wie die Konkurrenz genüßlich feststellt, "zumal die Anwendung mit VTAM, NCP/VS, IMS/VS, CICS/VS erheblichen Speicherplatz verlangt".

Bereits im Frühjahr 1975 war bei Auerbach publiziert worden, welche Speicher-Bedürfnisse beim Host-Processor durch SNA in den einzelnen Betriebssystem-Versionen entstehen. Es sind bei:

DOS/VS Batch-Minimum 160 KB mit SNA 320 KB

OS/VS2 Batch-Minimum 385 KB mit SNA 768 KB

OS/MVS.2 Batch-Minimum 768 KB mit SNA 1 - 1,5 MB

In der Regel bedeutet dies eine Verdoppelung des Speicherbedarfs. So ist SNA sicherlich auch ein Overhead-Problem Und der Hauptgrund, daß eine Reihe von SNA-Anwendern wieder absprang, war: Netzbetrieb mit "SNA bringt keine nachweisbaren Einsparungen". Dennoch überlegen sechzehn Prozent der befragten Benutzer von SNA-tauglichen Konfigurationen, dieses Netz über ihre Installation zu ziehen. Rund 75 Prozent dieser Interessenten fahren die 370 in 155/158- oder 165/168-Version.

Die größten Kopfschmerzen bereiten; bei der Anwendung von SNA die notwendige Software und die Schulung, während als Argument pro SNA der größere Durchsatz und die neuere Hardware angeführt werden. Höherer Durchsatz, obgleich SDLC-Einschränkungen darin bestehen, daß nur synchrone Datenübertragung möglich ist: Wer relativ geringe Datenmengen von vielen Außenstellen zu wenigen Zentralen übertragen will, fährt via Parallelübertragung besser. Überdies tritt bei der SDLC-Prozedur wegen der raschen Nachrichten-Bestätigung (ACK oder NAK nach jeder siebten Nachricht) oft eine relativ lange Wartezeit auf die Quittungsmeldung auf - wodurch die Leitung nicht gerade optimal ausgelastet wird.

In ganz neues Licht wurde das SNA-Konzept aber nunmehr durch die 8100 gerückt. Während ursprünglich absolute SNA-Voraussetzung SDLC-Terminals und VTAM waren (was durch die Möglichkeit, SDLC-Terminals unter TCAM zu betreiben allerdings schon ausgehöhlt wurde), kann nunmehr durch die 8100 sogar auf die SDLC-Kondition des Terminals verzichtet werden.

Systemkenner vermuten, IBMs-Flexibilität bei der Netzwerk-Architektur sei vor allem von den "Packet-Switching"-Alternativen der Konkurrenz (AT&T) verursacht.

Dennoch bleibt am SNA noch eine Menge auszusetzen. Und kritisch formulierte IDC die negativen Aussagen der Untersuchung zu dem Wortbild: "Anwender und SNA - eine problematische Hochzeit." Ex-IBM-Communications-Spezialist James Martin bündig über die SNA-Tauglichkeit für Distributed Processing:

- SNA unterstützt vor allem das Datenbankmanagement und die Netzwerk-Steuerung nicht, was gerade beim Distributed Processing wichtig sei, und

- SNA unterstützte bislang auch den internationalen X.25-Standard nicht, der für den Daten-Paket-Dienst entwickelt worden ist.

Freilich, ob die Kommunikation in offenen Netzen einen Markt hat, ob also das X.25-Interface mehr als eine Option sein muß, das ist jetzt noch nicht zu beantworten.

IBM wird ohnehin eher nein sagen.