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.

21.01.1994

Entwicklungstendenzen im Markt fuer Terminalemulationen PC-Host-Kommunikation heisst nicht mehr nur SNA und LU 6.2 Von Christoph Hammerschmidt*

Der Siegeszug der Client-Server-Technologie hat das Gesicht der PC-Host-Kommunikation in den letzten Jahren entscheidend veraendert. Verteilte Datenhaltung stellt nicht nur hohe Anforderungen an die Connectivity; auch fuer die Integration in PC- Software muessen sich die Hersteller etwas einfallen lassen.

Zum Dreh- und Angelpunkt der Client-Server-Technologie hat sich die Kommunikation zwischen Host und Arbeitsplatzrechner entwickelt. Sie muss unterschiedlichen Anforderungen gerecht werden, je nachdem, wo im Einzelfall die Trennlinie zwischen Client- und Server-Anwendung verlaeuft. Diese Verteilung bewegt sich zwischen zwei Extremen: einmal der voellig Host-orientierten Anwendung, bei der dem Arbeitsplatzrechner lediglich die Aufgabe zufaellt, die Daten in der Form auszugeben, wie sie der Host bereitstellt. Diesem Modell entspricht die klassische Terminalemulation ohne irgendwelche Finessen. Das andere Extrem besteht darin, dass der Host nur noch als Ablage und Archiv fuer die Daten dient, die der Arbeitsplatzrechner verarbeitet, aufbereitet und visualisiert.

LAN-Knoten ersetzen heute den SNA-Cluster-Controller

In diesem Spannungsfeld findet die Weiterentwicklung der Host- Kommunikation im wesentlichen unter zwei Aspekten statt: Connectivity und Funktionalitaet. Anders ausgedrueckt: Die Palette der anzapfbaren Datenquellen ist das eine Objekt der Entwicklerbestrebungen; das andere besteht in der Frage, wie sich die Faehigkeiten des PCs, dessen Rechenleistung ja viel billiger ist als die des Hosts, moeglichst umfangreich fuer die Verarbeitung von Host-Daten nutzen lassen. Der Flaschenhals, durch den die Daten hindurch muessen, ist in aller Regel die Terminalemulation.

Vor wenigen Jahren noch wurde jeder PC, der mit einem Host kommunizieren sollte, mit einer eigenen Adapterkarte ausgestattet und per Koax- oder Twinax-Kabel an einen SNA-Cluster-Controller angeschlossen. Dieser steuerte seinerseits den Datenverkehr mit dem Host. Mit zunehmender Vernetzung aendert sich das Bild: Die Aufgabe der Host-Anbindung wird heute einem dedizierten LAN-Knoten uebertragen, der als Gateway fungiert. Die Kommunikationsarchitektur als solche ist davon nicht tangiert. "Ein Gateway ist nichts anderes als ein emulierter Cluster- Controller" erlaeutert Roland Hollstein, Vertriebsleiter von Eicon Technology. Billiger als eine Einzelanbindung ist diese Loesung jedoch allemal, und leichter zu managen ebenfalls. Auch die Art der Verbindung zwischen Gateway und Host ist variabel geworden. Nicht nur die klassische SNA-Architektur wird fuer die Anbindung eingesetzt, sondern alles, was sich routen laesst. Dabei spielen wegen ihrer hohen Verbreitung TCP/IP-Protokolle eine besondere Rolle, und es gibt nicht wenige Bestrebungen, SNA-Verkehr auf TCP/IP-Strecken abzuwickeln. "SNA zu routen ist schwierig", meint Hollstein. In juengerer Zeit hat beispielsweise Cisco einen Versuch unternommen, mit der APPI-Technik (Advanced Peer to Peer Internetworking) IBMs APPN-Monokultur zu durchbrechen. Allerdings war der Vorstoss offenbar darauf angelegt, das blaue Lager unter Druck zu setzen, denn schon wenig spaeter einigten sich die Kontrahenten auf eine neue Lizenzpolitik, und Cisco kehrte in den Schoss von Mother Blue zurueck.

Trotzdem ist Pluralitaet angesagt. So unterstuetzt beispielsweise Novell mit "Netware fuer SAA" diese Art der Host-Kommunikation ebenso wie Microsoft mit seinem SNA-Server fuer Windows NT.

Gemeinsames Merkmal ist die Unterstuetzung unterschiedlicher Protokolle und Handling-Mechanismen, so dass sich das jeweilige LAN sowohl ueber APPC als auch ueber LU- beziehungsweise PU- Schnittstellen oder CPI-C an den Host anbinden laesst.

IBM-Hosts "verstehen" mittlerweile ebenfalls TCP/IP, so dass der Zwang zu SNA nicht mehr in dem Masse wie frueher gegeben ist. Natuerlich muss dann auch auf dem PC ein entsprechender Protokoll- Stack installiert sein. Produkte dafuer gibt es jedoch zuhauf. "Pathway" von Wollongong, "LAN Workplace" von Novell, "PC-NFS" von Sunsoft oder "PC/ TCP" von FTP sind nur einige Beispiele.

Auch auf der Ebene der Uebertragungsmedien ist Bewegung in die Szene gekommen. Direkte Einbindung des Hosts in das LAN ist laengst kein Thema mehr, wobei sogar die Polarisierung IBM und Token Ring einerseits sowie Ethernet und offene Systeme andererseits in Aufloesung begriffen ist. Im Weitverkehrsbereich treten X.25- (Datex-P)- und ISDN-Verbindungen allmaehlich an die Stelle ueberkommener Modemleitungen. Die Remote-Anbindung beispielsweise von Filialen und Aussendienstlern erfolgt haeufig ueber solche Dienste. Dabei beeinflusst die unterschiedliche Tarifstruktur von Datex-P und ISDN die verwendete Technik: Weil bei Terminalemulation meist kurze Datenpakete hin- und hergesandt werden, wobei die Verbindung selbst ueber einen laengeren Zeitraum aufrechterhalten bleibt, wird Datex-P mit seiner volumenorientierten Abrechnungsmethode in der Regel ISDN vorgezogen.

"Bei einer Aenderung der Gebuehrenstruktur waere ISDN auch interessant", meint Hollstein. Der integrierte digitale Dienst ist jedenfalls im Kommen. Im Routing-Bereich wird ISDN auch vom LAN- Marktfuehrer Novell unterstuetzt. Im uebrigen gibt es auch Mischformen, etwa das Protokoll X.31. Damit laesst sich Datex-P- Verkehr ueber ISDN als Traegermedium abwickeln. In Zukunft sind noch hoehere Datenraten angesagt: "Der Trend geht zum direkten Kanalanschluss", davon ist Hollstein ueberzeugt.

Dabei handelt es sich nicht nur darum, Daten mit einem einzelnen Host auszutauschen. Die Erfordernisse der verteilten Datenhaltung bringen es mit sich, dass ein Arbeitsplatz gleichzeitig an mehreren Hosts eingeloggt sein muss. So unterstuetzt die Kombination Netware fuer SAA auf dem Gateway und "PC Support" auf der Workstation gleichzeitig bis zu 32 AS/400-Host-Sessions pro Arbeitsplatz. Es geht auch multikulturell: Benutzer von Wall Datas Host- Kommunikationspaket "Rumba" beispielsweise koennen simultane Sessions auf einem IBM-Mainframe, der AS/400 und DECs VAX oder einem Unix-Host ablaufen lassen und die Daten in einer PC- Anwendung zusammenfuehren.

Damit sind wir bei dem zweiten grossen Gebiet, auf dem sich die Entwickler der PC-Host-Kommunikation austoben: der Funktionalitaet der Softwareloesungen. Die einfachste Art, Host-Daten zu verarbeiten, besteht darin, sie anzuschauen. Dafuer gibt es seit eh und je Terminalemulationen. Diese Programme verfuegen traditionell ueber die Moeglichkeit, Dateien hin- und herzutransferieren. Heutigen Anspruechen genuegen diese simplen Mechanismen jedoch nicht mehr. "Die Terminalemulation bleibt unser Kernprodukt", erlaeutert Peter Fischer, Sales Engineer bei DCA Deutschland. "Aber der Trend zu Client-Server erzwingt die Integration von Mechanismen wie DDE."

Die Entwicklung geht dahin, Host- und PC-Anwendungen miteinander zu verzahnen und den PC ausgewaehlte Host-Daten weiterverarbeiten zu lassen. Die Auswahl der Host-Daten soll dabei soweit als moeglich softwaregesteuert und ohne Zutun des Endanwenders erfolgen. Und schliesslich fordert auch die Ergonomie ihren Tribut: Die Host-Anwendungen sollen mit der Maus zu bedienen sein, PC- adaequate Bedienungselemente wie beispielsweise Windows- Schaltflaechen oder Listenfelder dem User das Leben mit dem Host erleichtern.

Eine einfache Art, Host-Daten in eine PC-Anwendung zu uebernehmen, ist das Drag-and-drop-Verfahren. Das Nonplusultra an Komfort bietet dieses Vorgehen jedoch nicht: Der Benutzer muss die fraglichen Daten manuell auswaehlen und sie in seine PC-Anwendung hinueberziehen. Auch der vielfach angewandte Umweg ueber die Windows-Zwischenablage ist sicherlich nicht der Weisheit letzter Schluss. Schon fortschrittlicher mutet der Einsatz von Dynamic Data Exchange (DDE) an. Damit lassen sich beispielsweise Buchungsdaten vom Host ohne sichtbare Nahtstelle in eine PC-Tabellenkalkulation uebernehmen. Aendern sich die Host-Daten, wird die Bildschirmdarstellung auf dem Arbeitsplatzrechner sofort und selbstaendig nachgefuehrt.

Host-Anwendungen unterstuetzen jedoch diesen Mechanismus nicht; er ist zur Zeit nur unter PC-Betriebssystemen wie OS/2, Windows und Windows NT moeglich. Die diversen Anbieter von Software fuer die Host-Kommunikation muessen sich daher einer Kruecke bedienen: Die PC-Software uebernimmt einfach den Zeicheninhalt einer zuvor definierten Bildschirmregion. Der Nachteil: Wird der Aufbau des Host-Bildschirms geaendert, so funktioniert auch die PC-Anwendung nicht mehr und muss entsprechend nachgefuehrt werden.

Die Interaktion mit dem Host laesst sich im Zeichen moderner grafischer Benutzerfuehrungen noch weiter treiben: Wo der Host per Terminalbildschirm und Kommandozeile eine Tastatureingabe erwartet, erscheint auf dem PC-Bildschirm eine Windows- oder OS/2- Schaltflaeche, die sich mit der Maus anklicken laesst. Mit Betaetigung des Buttons sendet die PC-Software eine der jeweiligen Funktion entsprechende Zeichenfolge an den Host; komplizierte Log-on- Vorgaenge und Kommandos mit vielen Parametern verlieren so ihren Schrecken fuer den Sachbearbeiter. Zugleich wird das Potential fuer Falscheingaben drastisch gesenkt.

Eine weitere Moeglichkeit fuer die Integration von Host-Funktionen in PC-Anwendungen eroeffnet sich durch die Schaffung eigener Funktionsleisten mit spezifischen Icons auf dem Macintosh-, Windows- oder OS/2-Bildschirm. Wichtige Standardfunktionen des Hosts bedient der Enduser dann in Form einer Symboltaste im Stil des jeweiligen Arbeitsplatzsystems.

Auf diese Weise lassen sich natuerlich nur elementare Funktionen darstellen. Fuer benutzerspezifische und staerker differenzierte Eingaben gibt es andere Wege. So kann der User ueber eine virtuelle Zusatztastatur auf dem Bildschirm die wichtigsten Anwendungen starten, Druckvorgaenge ausloesen und dergleichen mehr.

Heutige Terminalemulations-Produkte muessen intern programmierbar sein, wollen sie auf dem Markt bestehen. Am einfachsten laesst sich dies mittels Makroprogrammierung realisieren: Eine Abfolge von Tastatureingaben wird gespeichert und einer Keyboard-Taste, einem Menuepunkt oder einem Button auf dem GUI zugeordnet. Weitergehende Integrationsfunktionen bieten eigene Script-Sprachen, die viele Produkte enthalten. Neuerdings haeufig anzutreffen ist ausserdem die Moeglichkeit, selbstenwickelte Programme in "Visual Basic" einzusetzen. Besonders im Zusammenspiel mit Microsoft- Applikationen auf dem PC lassen sich auf diese Weise Host- und PC- Anwendung eng miteinander verknuepfen.

Den letzten Schritt zu einer komplexen Client-Server-Applikation auf Basis von Terminalemulations-Programmen ermoeglicht das Emulator High Level Language Application Program Interface (EHLLAPI) von IBM. Ueber diese Schnittstelle koennen auch Programme in Hochsprachen wie Cobol, Fortran oder C mit Host-Anwendungen kommunizieren und auf Mainframe-Daten zugreifen.

Ein Sorgenkind der Host-Kommunikation sind seit eh und je die unterschiedlichen Tastaturen von PC und Terminal. Beispielsweise verfuegt ein PC nur ueber zwoelf Funktionstasten; bei einem 3270- Terminal sind es deren 24. Aehnlich verhaelt es sich mit Enter- und Return-Taste. Anbieter von Terminalemulations-Paketen behelfen sich mit virtuellen Bildschirmtastaturen. Diese Loesung erfordert jedoch ein haeufiges Umgreifen: Die Bildschirmtasten lassen sich nur mit der Maus bedienen.

Tastatur-Editoren, wie sie in "Open Connect TN5250" enthalten sind, bieten eine gewisse Erleichterung. Ueber eine Bildschirmdarstellung der Tastaturen lassen sich Host-Funktionen dem PC-Keyboard zuordnen. Das spart dem Entwickler oder dem User- Support eine Menge Arbeit, doch der Endanwender hat wenig davon: Er muss sich noch mehr Tastenbelegungen merken.