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.

05.05.1989 - 

LU 6.2 Peer-to-Peer-Kommunikation

Der PC befreit sich von der Mainframe-Hierarchie

In größeren Unternehmen hatte die zentrale DV-Abteilung bis zum Erscheinen der PCs und einige Zeit danach eine Monopolstellung. Allerdings hat der PC mit der Zeit einen hohen Verbreitungsgrad und hohe Akzeptanz beim Anwender erzielt. Dieser hat gelernt, daß EDV nicht nur aus Software besteht, vielmehr lernte er mehr über Systemtechnik und deren Arbeitsweise und wurde dadurch selbständiger und mündiger. Durch sein gesteigertes Selbstbewußtsein erhöhte sich seine Lernbereitschaft und Motivation. Er verlangte nach mehr Kompetenz und entwickelte seine eigenen "Insellösungen".

Diesen jetzt bestehenden zwei DV-Welten werden die klugen DV- Manager dadurch gerecht, indem sie gezielt der erhöhten Kompetenz des Anwenders durch Kooperation Rechnung tragen. Das bedeutet Integration der PCs in die große IBM-Welt durch gezielte Funktionsverteilung.

Seit der Einführung 1974 entwickelte sich SNA in zwei Richtungen. Traditionell verband es Mainfraimes und unintelligente Terminals (oder Drucker) nach streng hierarchischen Prinzipien. Andere, nicht IBM-Devices, konnte man entweder durch die Funktion eines interaktiven 3270-Terminals oder über 3770 RJE (Remote Job Entry) anschließen.

Bei der Anbindung beziehungsweise Integration von PCs mit Mainfraimes der IBM-Welt wurde in der Anfangszeit ein 3270-Terminal mit einiger Zusatzintelligenz und Funktionen realisiert. Letztere beschränkten sich allerdings auf eine einfache 3278 -Terminalemulation beziehungsweise eine Filetransfer-Funktion vom/zum Host.

DOS-Programme schränkten die Emulationen zunächst ein

Das Problem dabei war, daß Emulation und Transfer als DOS- Programm im Vordergrund liefen und somit kein Parallelbetrieb möglich war. Nach und nach tauchten dann Lösungen auf für 3279-Emulation (Farbe) sowie 3279/3179G (mit Farbgrafik), während der Filetransfer in den Hintergrund wanderte.

Beim herkömmlichen 3270-Betrieb beschränkte sich die Funktionalität auf die oben erwähnte Funktion. Die mit diesen Werkzeugen praktizierte Integration des PCs beschränkte sich also auf Daten holen/verarbeiten/ senden. Weiterentwicklungen waren hauptsächlich im Bereich "Verarbeiten" zu sehen. Es wurden Programme für den PC entwickelt, die die vorhandenen Daten exakt in der gleichen Weise verarbeitet haben wie das im Host geschah. Daraus entstanden dann beispielsweise PC-CICS oder PC-GDDM.

Ein weiteres Problem, das den PC-Benutzern zusätzlich zu schaffen machte, war der Speicherbedarf. Da die 3270-Emulations-Software (Terminalemulation und Filetransfer) in den meisten Fällen 140 bis 200 Kilobyte schluckt, bleibt im Regelfall nicht allzuviel Speicher für weitere DOS-Anwendungen übrig. In manchen Fällen muß dann der PC für die jeweilige Aufgabe (Emulation oder DOS-Programm) mit dem entsprechenden Environment neu gebootet werden. Diese Lösungen konnten zwar den Host etwas entlasten. Da aber die eigentliche Verarbeitung inklusive Aufbereitung zum Senden oder Nacharbeit beim Empfangen immer noch beim Host lagen, konnte seine effektiv spürbare Befreiung stattfinden.

Ansätze zu neuen Lösungen entstanden dann noch auf Basis der 3270. Sie sollten über den Filetransfer hinausgehen und eine direkte Kommunikation zwischen einer lokalen PC-Applikation und einem Hostprogramm schaffen. Der Weg, der hier beschritten wurde, lag in der SW-Nachbildung eines Terminals und dessen Arbeitsweise. Der Host kommunizierte also mit einem 3270-Terminal, das gar keines war. Damit konnte man weitere Zusatzfunktionen in den PC verlagern, bekam aber einen großen Overhead an unnötigen Interaktionen zwischen PC und Host.

Neue Impulse kamen dann mit der Realisierung von LU 6.2. War bis dahin eine hierarchische Programm-Programm-Kommunikation innerhalb SNA auf Hostprogramme beschränkt, schloß die LU 6.2 auch PCs mit ihren Applikationen mit ein. Sie löst einige Probleme von SNA. Da hierbei keine hierarchische Prozeßstruktur mehr vorhanden ist, können Programme in Workstations, Minis und Mainframes beliebig untereinander Daten direkt austauschen, ohne sich in den Host "einzuloggen" oder als ein einfaches Terminal zu agieren. Jeder in dieser Peer-to-Peer- Verbindung ist gleichberechtigt. Darüber hinaus können so Programmnetzwerke gebildet werden die völlig selbständig arbeiten. Ein Eingriff ist nur in beim Auftritt von Fehlern erforderlich.

LU 6.2 gibt dem PC die gleichen Rechte wie dem Host

Außerdem ermöglicht LU 6.2 die Remote-Ausführung von Programmen unabhängig davon, wo Sie oder der Aufrufer sich im Netzwerk befinden. Zur Zeit ist das Verlangen nach LU 6.2 noch nicht sehr groß, weil die 3270-Arbeitsweise in den meisten noch laufenden IBM-Mainframe- Applikationen integriert ist. Bisher wurden auch noch wenige Applikationen entwickelt, die LU 6.2 benutzen würden, obwohl dieser Standard bereits in CICS implementiert ist.

Mittels LU 6.2 und dessen APPC (Advanced-Program-to-Program-Communikation) können sich zwei Programme/Applikationen unabhängig voneinander miteinander unterhalten. Dabei sind beide völlig gleichberechtigt. Diese Arbeitsweise funktioniert natürlich ohne Einschränkung in der Host-Welt unter einander. Einschränkungen sind zu erwarten bei der Peer-to-Peer-Kommunikation zwischen einem Host und einem DOS-PC. Da der PC einerseits mit DOS keine Möglichkeit hat im Hintergrund die kommunizierende Applikation zu starten, andererseits der PC abgestürzt, abgeschaltet oder sonst gestört sein kann, kann das Hostprogramm nicht immer dann mit dem PC "sprechen", wann es muß.

Der PC benötigt viel Speicherplatz

Ein weiteres Problem, das sich PC-seitig beim Einsatz von LU 6.2 ergibt, ist ein gegenüber 3270 noch höherer Speicherbedarf. Ein Einsatz von LU 6.2 mit Peer-to-Peer-Kommunikation bis zur PC-Ebene ist auf breiter Basis eigentlich erst dann zu erwarten, wenn durch das PC-System folgende Anforderungen erfüllt werden:

- Ausreichend Speicher sowohl für Kommunikation als auch für Applikation,

- mehrere, auch Hintergrundprozesse lauffähig, um Software-seitig eine permanente Kommunikationsfähigkeit zu gewährleisten,

- permanent laufendes System mit Sicherheitsmechanismen für Ausfall/Absturz.

Als erste Adresse bieten sich natürlich PCs mit Unix an, die einmal die oben genannten Punkte erfüllen und für die darüber hinaus bereits von mehreren Herstellern entsprechende Produkte angeboten werden (3270 SNA, RJE-SNA, APPC mit LU 6.2). Als zweite Alternative besteht die Möglichkeit, die oben genannten Punkte unter OS/2 zu berücksichtigen

Im Vergleich zu den Kommunikations-Konventionen von IBM wie SNA/LU 6.2/etc. sollte eine Secondsource-Möglichkeit erwähnt werden. Das im Unix-, PC- und Mini-Bereich mittlerweile weit verbreitete Ethernet mit TCP/IP und den mitgelieferten Utilities wie ARPA/TELNET/ FTP sowie zur Prozeß-Prozeß-Kommunikation verfügbaren Sockets. Seit einiger Zeit wird auch von SPARTACUS TCP /IP für Mainframes (IBM) angeboten, das die gleichen Möglichkeiten wie oben bietet. Eine Verbindung PC-Host ist da physikalisch praktisch an jeder Stelle des Ethernet- Netzwerks möglich. Dann stehen dem PC die gleichen Funktionen wie unter 3270 Emulation zur Verfügung (Filetransfer, Terminalemulation), darüber hinaus die Möglichkeit eines Remote-Login in jeden Rechner, in dem er diese Zulassung besitzt. Die Fähigkeiten, die LU 6.2 mit Peer-to-Peer bietet, können über TCP/IP mit Sockets realisiert werden, allerdings gelten unter DOS dieselben Einschränkungen wie bei LU 6.2. Der PC-Anwender erfreut sich dabei eines mit rund 20 bis 40 KB geringeren Speicherbedarfs seiner TCP/IP-Software .

Wie wir sehen, macht die Innovation auch vor der Verbindung eines PC mit dem Host nicht halt, und das ist gut so, denn mit dem Schritt zur echten Prozeß-Prozeß-Kommunikation wird die Einbindung von leistungsfähigen PCs in Mainframe-Anwendungen erst interessant.

Wichtig ist allerdings, daß auch Kommunikations-Alternativen entwickelt und in Abhängigkeit von deren Leistungsmerkmalen sowie den Anwendungserfordernissen eingesetzt werden.

Andererseits, und das tritt immer stärker ans Tageslicht, sind neue vernetzte Anwendungssysteme ohne den Einsatz eines leistungsfähigen und ausgereiften PC-Betriebssystems sinnlos.