Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

09.02.1979

SNA - noch immer nur beschränkt tauglich

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.