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.

27.06.1986

Terminalemulation ist noch nicht das Nonplusultra

Die Kommunikation zwischen Mikro und Host gestaltet sich bei einer Reihe bundesdeutscher Unternehmen nach wie vor problematisch. Hilfestellung hierbei versprechen Anbieter von Terminal-Emulationskarten: Diese sollen es ermöglichen, den Arbeitsplatzrechner als funktionsfähiges Terminal einzusetzen, aber auch Freiraum für individuelle Anwendungen beim Endbenutzer lassen. Joachim Schulz von den Bonner Vereinigten Aluminium-Werken moniert hingegen: "Wir verfügen zwar über Emulationskarten in unseren Mikros, aber ungelöst sind weiterhin viele Hard- und Software-Probleme." Klaus Hollmann, Leiter der systemtechnischen Dienste bei Merck, beklagt den Mangel an Standards. In dem Darmstädter Unternehmen beschränkt sich daher die Mikro-Mainframe-Kommunikation auf spezielle Anwendungen. Betont Hollmann: "Applikationen, wie sie vom Mikro her bekannt sind, bleiben Jedoch weiterhin lokal."

Klaus Hollmann, Abt.-Leiter Systemtechnische Dienste, Merck, Darmstadt

Wir hatten uns vorgenommen, unsere Anwendungen über LU 6.2 laufen zu lassen, da alles andere für uns nur als Zwischenlösung angesehen wird. Ferner haben wir ein nicht geringes Problem: Derzeit verfügen wir noch über Remote-Anschlüsse und dies ist für eine Mikro-Mainframe-Verbindung unter Umständen eben nicht ganz einfach. Es gibt hier keinen Standard. Wir haben vier 3274-Koax-Anschlüsse mit einer Lochkarte, die eine einigermaßen vernünftige Kommunikation ermöglicht. Es liegt in bezug auf eine echte Mikro-Mainframe-Kommunikation zwar eine Konzeption vor, doch wird es noch etwas Zeit in Anspruch nehmen, bis alles vollständig genutzt werden kann.

Zwischenzeitlich haben wir mit Einsatz der Forte-Link-Karte eine fast gleichwertige Lösung wie bei LU 6.2 erreicht, die nur geringfügige Abweichungen aufweist. Ein für uns wichtiger Aspekt war die Möglichkeit des dezentralen Drucks und insbesondere das Downloading von Programmen. Gerade der letztere Punkt ist von entscheidender Bedeutung, wenn man bedenkt, daß sich hier immerhin rund 400 Mikrocomputer befinden. Es ging also primär weniger darum, Applikationen wie Multiplan verfügbar zu haben, sondern mehr um den Aufbau von effektiven Programmiersprachen beim Host, wie beispielsweise Super-Natural, später dann auch SAS oder IC1. Prinzipiell bleiben jedoch Anwendungen, wie sie vom Mikro her bekannt sind, weiterhin lokal: Multiplan, Grafik oder Text finden sich hier wieder.

Momentan sind wir dabei, auch den Bereich der Textverarbeitung mit in dieses Konzept einzubeziehen. Das Herunterladen von Daten ist jedoch eine Sache, die wir derzeit nicht so sehr angehen, weil wir dies zentral aufbereiten. Die Mikro-Mainframe-Kommunikation in unserem Hause beschränkt sich - nicht zuletzt aufgrund der großen Zahl von Mikros - auf von uns kontrollierte Anwendungen. Das ursprüngliche Konzept sah eine reine Form der Bürokommunikation vor, was seinerzeit auch die Frage aufwarf, ob eine 3270 im Remotebetrieb angeschafft werden sollte, oder andererseits die Entscheidung zugunsten von mehreren PCs fällt, die anschließend in ein Text-Kommunikationsnetz eingebunden werden sollten. Vielleicht fällt auch eines Tages die Entscheidung zugunsten einer Token-Ring-Lösung, die dann das jetzige Konzept wieder überholungsbedürftig macht. Entscheidend dabei ist, welche konkreten Applikationen dann gefordert sind.

Joachim Schulz, DV-Leitung, Vereinigte Aluminium-Werke AG, Bonn

In bezug auf eine Mikro-Mainframe-Kommunikation existieren bei uns sicherlich gewisse Probleme, die aus den unterschiedlichen Anforderungen resultieren. Wir befinden uns damit in einer Phase, wo wir Datentransfer zwar bereits durchgeführt, aber festgestellt haben, daß hier noch einige Mängel vorhanden sind, die aus dem Weg geräumt werden müssen. Vor allem gilt es, herauszufinden, welche Auswirkungen dies auf den späteren Dialogbetrieb haben wird. Da kommt dann beispielsweise die Frage nach der Länge der jeweiligen Antwortzeiten auf.

Parallel dazu muß geprüft werden, wie der organisatorische Ablauf des Datentransfers für den Anwender später einmal aussieht.

Wir haben vorwiegend Mikrocomputer von Olivetti und IBM, wobei wir für die M24-Maschinen auch entsprechende Zusatzkarten eingebaut haben, die eine Terminalemulation ermöglichen. In diesem Bereich gibt es aber noch eine Vielzahl von Problemen, die sowohl hardwareseitig als auch softwareseitig angesiedelt sind. Zwar läuft dies bei uns alles prinzipiell, doch sind wir jetzt in einer Phase, in der wir eigentlich umfangreichere Tests fahren müßten, um beispielsweise die Funktionsweise der 3274-Cluster-Controller eingehend zu überprüfen. Gerade hier muß festgestellt werden, wie das Antwortzeitverhalten in der Praxis aussieht, oder wie der Cluster-Controller die hohen Übertragungsraten verkraftet. Denn liegen die Antwortzeiten zum Beispiel im Minutenbereich, dann wäre dies für den Dauereinsatz sehr problematisch.

Der erste Ansatzpunkt für eine aus unserer Sicht sinnvolle Konfiguration war die Frage nach den Anwendungen, die einerseits den Anschluß an den Mainframe unumgänglich machten, andererseits aber auch den Einsatz von Standalone-Mikros erforderten. Damit stand fest, daß zwei Geräte, nämlich Terminal und Mikro, nicht in Frage kommen würden. Also führte dies zum Einsatz von Mikrocomputern, die mit Hilfe einer Terminal-Emulationskarte beide Funktionen in sich vereinigen konnten. Ferner war die Überlegung, daß bestimmte Fachbereiche ihre individuelle Datenmenge vom Hostrechner verfügbar haben mußten ausschlaggebend. Dieser Datentransfer sollte damit per Downloading erfolgen, auf dem Mikro sollte beispielsweise mit Programmen wie Multiplan die Aufbereitung dieser Daten durchgeführt werden, die dann auch wieder individuell auf den Host zurücktransferiert werden können.

Das Konzept sah somit die Einrichtung eines echten multifunktionalen Arbeitsplatzes vor. Im Moment steigt die Zahl der neu installierten Mikros, die eine Terminalemulation ermöglichen, ständig. Für uns erscheint diese Lösung am sinnvollsten, weil eben zweigleisig gefahren, und der Mikro mit geringem Aufwand zu einem Terminal modifiziert werden kann. Auf der Hostseite fahren wir in erster Linie Cics-Anwendungen und unter Cics Applikationen, mit denen Dinge wie Materialwirtschaft, Finanzbuchhaltung, Vertrieb und ähnliches abgewickelt werden. Darüber hinaus können wir auf Pakete wie Adabas oder Paisy zurückgreifen. Als Mainframes kommen eine Siemens 7.890, eine Siemens 7.860 und eine IBM 4381-3 zum Einsatz; alle diese Systeme sind miteinander verbunden. Sicher kommen im Lauf der Zeit noch Verbesserungen hinzu, um ein Optimum verfügbar zu haben, doch kann die Lösung, wie sie sich jetzt bei uns präsentiert, im Prinzip als endgültig angesehen werden.

Hanns-Joachim Reckert, DV-Leiter, Peek & Cloppenburg, Düsseldorf

Wir haben mit der Forte-Emulationskarte gute Erfahrungen gemacht. Wir fahren beispielsweise Anwendungen unter Roscoe, können aber parallel dazu auch Cics-Applikationen fahren. Als Hostrechner kommt bei uns eine BASF 7/73 zum Einsatz, die mit der 4381 von IBM vergleichbar ist. Im Unternehmen haben wir zwölf Mikrocomputer, von denen vier mit der Forte-Karte ausgerüstet sind. Geplant ist der weitere Ausbau von Mikros mit dieser Emulationskarte. Des weiteren haben wir in einem dieser Systeme noch eine Petra-Karte, die mit der Irma-Karte vergleichbar ist, installiert. Damit lassen sich ohne Schwierigkeiten Daten vom Mainframe auf den Mikro herunterladen und dort entsprechend weiterverarbeiten.

Was uns zu diesem Schritt bewogen hat, war einerseits die Einfachheit der Installation dieser Karten. Zudem hatten wir den Eindruck, daß das Antwortzeitverhalten in dieser Form wesentlich günstiger liegt als beim Terminal. Als weiterer Vorteil kam hinzu, daß auch eine Kommunikation bei den Mikros untereinander stattfinden kann, was ebenfalls über den Hostrechner läuft. Die wichtigsten Aspekte, die diesem Konzept zugrunde lagen, waren die Anforderungen, die von seiten der Fachabteilungen kamen. Mit dazu zählen natürlich auch Aspekte wie die Datensicherung, die auch über den Host direkt betrieben werden kann.

Die ursprüngliche Planung stand bei uns fest und wurde von der Fachabteilung eigentlich nur durch Denkanstöße weiter verbessert. Bis jetzt befinden wir uns sozusagen noch in einer Übergangsphase und es muß weiter versucht werden, hier noch einige Dinge grundlegend zu verbessern, damit möglichst bald ein endgültiger Status erreicht wird. Sicherlich werden damit auch in Zukunft noch weitere Mikros an den Host angehängt werden, um einen noch effektiveren Zugriff zu erzielen.