Wenn Datenverarbeitungsfachleute über Host- und Mikrocomputer-Kommunikation sprechen, tauchen immer wieder zwei Schlagworte auf: der Mikro als Host-Terminal und File-Transfer. Bei eingehender Analyse zeigt sich jedoch, daß weder eine Bildschirm-Emulation noch ein File-Transfer das ist, was ein Unternehmen zur Informationsverarbeitung konzeptionell benötigt.

Zur Verdeutlichung sei zunächst ein typischer Fall ohne File-Transfer betrachtet: Ein hypothetisches Unternehmen in München hat ein IBM-System /38 mit 40 angeschlossenen Bildschirmen installiert. An operativen Anwendungen ist so ziemlich alles vorhanden, was denkbar ist. Da ein Mitbewerber seine Rabattstruktur geändert hat, will Herr Fach, Leiter Finanzplanung und Kontrolle, untersuchen, ob das eigene Rabattstruktursystem geändert werden sollte. Dazu benötigt er Kunden-, Umsatz- und Produktinformationen, die auf dem System /38 mit Sicherheit vorhanden sind. Obwohl er schon oft einen negativen Bescheid bekommen hat, geht er zu Herrn Daten, dem Leiter Datenverarbeitung. Es kommt zu folgendem, klassischen Dialog:

HERR FACH: "Ich brauche bis Freitag unbedingt eine kleine Auswertung in der Form XY "

HERR DATEN (STIRNRUNZELND): "Bis Freitag?" (Heute ist Dienstag.)

HERR FACH: "Ja, wir wollen untersuchen, ob wir unsere Rabattstruktur ändern müssen."

HERR DATEN: "Bis Freitag schaffen wir das auf keinen Fall. Haben Sie das nicht schon vor sechs Wochen gewußt?"

HERR FACH: "Unser größter Mitbewerber hat erst gestern seine Rabattstruktur geändert. Ich brauche doch nur . . ."

HERR DATEN: "Nur ist gut! Wir müssen neue Programme schreiben, Dateien aufbauen und außerdem erst einmal genau definieren, was Sie brauchen. So in zirka vier Wochen . . ."

Wieder einmal mehr sieht sich Herr Fach in seiner Meinung bestätigt, daß die zentrale DV ihm bei der Lösung seiner Probleme ohnehin nicht helfen kann. Herr Daten hingegen ärgert sich über die x-te Forderung an diesem Tag nach der berühmten "kleinen Liste". Ergebnis: Die Entscheidung am Freitag findet ohne fundiertes Zahlenmaterial statt, die Unternehmensleitung muß sofort auf die Rabattänderung des Konkurrenten reagieren.

Ein typischer Fall mit Bildschirmemulation und File-Transfer ist der folgende:

Das hypothetische Unternehmen hat zwei Kleinrechner eingesetzt. Eine spezielle Mikro-Karte ermöglicht es dem Mikro, sich als 52xx-Modell-11-Bildschirm zu verhalten. Über ein File-Transfer-Programm können Daten vom System /38 zum Mikrocomputer geschickt werden.

Herr Fach ist nun stolzer Besitzer eines Mikro und hat gehört, daß man damit alles machen kann. Er muß nur die Daten vom Host zu seinem Arbeitsplatzrechner bringen und jemanden finden, der ihm ein paar kleine Programme schreibt. Am Freitag findet eine Sitzung statt, da ein Mitbewerber seine Rabattstruktur geändert hat.

Herr Fach geht zu Herrn Daten:

HERR FACH: "Ich brauche bis Freitag unbedingt eine kleine Datei auf meinem PC und ein paar Basic-Programme."

HERR DATEN (STIRNRUNZELND): "Bis Freitag?" (Heute ist Dienstag.)

HERR FACH: "Ja, wir wollen . . ."

Den Rest können wir uns sparen, auch diese Freitagssitzung wird ohne fundiertes Zahlenmaterial stattfinden.

Basierend auf den im Münchner Unternehmen geschilderten Umständen ergeben sich folgende aufgabenorientierte Zielsetzungen einer Host-Mikro-Kommunikation:

- Wird ein Mikrocomputer eingesetzt, so sollten dem Anwender auf diesem Rechner Instrumente zur Verfügung stehen, mit Hilfe derer er die vom Zentralrechner kommenden Daten selbständig verarbeiten kann.

- Diese Instrumente müssen problemlos vom Anwender mit Host-Daten versehen werden können, ohne daß die DV-Abteilung zusätzlich belastet wird.

Für den Mikrocomputer gibt es schon lange zahllose Instrumente zur flexiblen Behandlung von Daten. Stellvertretend für viele andere seien genannt: Lotus/Symphony, Framework, Multiplan und Open Access. Im wesentlichen handelt es sich hierbei um sogenannte "Spreadsheet"-Programme oder auf Deutsch "elektronische Formulare".

Das Blatt Papier der täglichen Arbeit wird auf den Bildschirm übertragen. Auf dem leeren Schirm entwikkelt der Benutzer elektronische Formulare mit Zeilen und Spalten. Diese werden mit Bezeichnungen versehen und anschließend manuell mit Zahlen gefüllt. Die Zahlen sind mit Rechenoperationen verbunden, und die Ergebnisse sind neue Zahlen (Informationen).

Die genannten Instrumente lassen sich hervorragend für Aufgabenstellungen wie Finanzplanung, Cashflow-Planung, Soll/Ist-Vergleiche oder Produktanalysen. Der Benutzer muß keine Programmieraufträge mehr vergeben, um Daten auszuwerten. Wer schon beispielsweise mit Lotus oder Multiplan gearbeitet hat, wird bestätigen, daß diese Aussage kein Wunschdenken ist.

Woher kommen nun die Daten? Auch die einfachsten, in den Fachabteilungen eingesetzten Mikrocomputer-Anwendungen haben einen gravierenden Nachteil: Damit man mit ihnen arbeiten kann, müssen Daten geliefert werden. Und diese Daten sind auf der zentralen Anlage ohnehin vorhanden. Es wäre nun ein Fehler, die Arbeitsplatzrechner unentwegt mit Listen zu versehen, um auf diese Weise den Datenhunger zu stillen:

- Programme für Listen müssen auch erst geschrieben- werden. (Programmierung).

- Anwender haben auch die Eigenschaft, bei der Dateneingabe Fehler zu machen.

- Listen in Verbindung mit Arbeitsplatzrechnern produzieren eine nicht mehr überschaubare Datenredundanz.

- Der Anwender will immer neue Listen haben, um seinen Mikro damit zu füttern.

Es wäre aber auch falsch, einfach Daten vom Host zum Mikro zu schikken.

- Die zu transferierenden Dateien müssen auch erst erstellt werden.

- Der Mikrocomputer-Anwender muß diese Dateien in seine Instrumente integrieren. Und da stimmen dann meist die Formate nicht.

- Der Mikro-Benutzer wird immer wieder nach neuen Dateien fragen, denn er benötigt ja immer neue Daten für immer neue Auswertungen.

Und kommt die DV-Abteilung gar den ständig neuen Forderungen nach Listen, Dateien und Mikrocomputer-Programmen nicht nach, dann passiert folgendes:

Das hypothetische Münchner Unternehmen hat nach kürzester Zeit drei DV-Abteilungen: Eine arbeitet mit dem System /38, zwei weitere haben sich um die beiden Mikros herum etabliert. Eine Reihe von Unternehmen sind mit dieser Situation konfrontiert.

Das hier skizzierte Konzept einer integrierten Host-PC-Verbindung verlangt eine Voraussetzung: den selbständigen und mündigen Anwender in der Fachabteilung. Und die Datenverarbeiter sollten nicht den Trugschluß ziehen, daß es so etwas nicht gibt.

Ganz im Gegenteil. Die meisten Mikro-Anwendungen sind so einfach und mächtig, daß ein Controller, der intensiv mit Lotus arbeitet, meinte: "Das ist genau das, was ich seit Jahren gesucht habe, aber von meiner Datenverarbeitung nie bekommen habe." Allein in dieser Aussage ist schon die Gefahr der Verselbständigung eines Mikrocomputers vorprogrammiert. Und da der Geschmack ohnehin beim Essen kommt, wird dieser Controller selbständiger und selbständiger.

Was ist also zu tun, damit die Mikros der Fachabteilungen in die Datenwelt des Hostrechners integriert werden? Nachdem der Begriff "Integration" in diesem Zusammenhang erklärt ist, wird sofort klar, welche Instrumente zur Realisierung notwendig sind. Integration im Zusammenhang mit Host-Mikro-Kommunikation heißt:

- Der Arbeitsplatzrechner ist "online" mit dem Host verbunden.

- Die PC-Benutzer können selbständig Daten auf dem Host selektieren und zu ihrem Arbeitsplatzrechner transferieren.

- Der Anwender kann wiederum selbständig bestimmen, welche Formate seine zum Mikro transferierten Daten haben. Dies ist wichtig, damit er problemlos mit seinen Standardanwendungen weiterarbeiten kann.

- Die Host-Daten werden nicht als Datei transferiert, sondern sind direkt in die Mikro-Anwendungen integriert.

Fazit: Einmal eingerichtet, sollte die Host-Mikrocomputer-Kommunikation ohne permanentes Eingreifen der DV-Abteilung dem Anwender als Informationszentrum dienen.

Die notwendigen Instrumente

1. 52xx-Emulation

Auch für die /34-, /36-, /38-Welt gibt es inzwischen Emulationskarten, die aus einem Kleinrechner einen voll funktionsfähigen 52xx-Bildschirm machen. Er ist dann wahlweise ein Mikro mit allen Mikrocomputer-Eigenschaften oder Host-Bildschirm.

2. Selektion und Extraktion von Host-Daten

Der Anwender soll in der Lage sein, auf Feldebene Daten zu selektieren. Auch dieses Instrument ist verfügbar und es wird zahlreichen Unternehmen mit Systemen /3x bereits eingesetzt.

Im wesentlichen erhält der Anwender über ein Wörterbuch (Data-Dictionary) Auskunft darüber, in welchen Dateien des Hostrechners /3x er seine Daten findet; im Dialog mit dem Host definiert er dann, welche Daten er haben möchte. Die Daten werden extrahiert und für den Transfer zum Mikro bereitgestellt.

3. Automatische Formatanpassung

Die Host-Tfansfer-Datei muß automatisch in das Mikro-Datenformat umgesetzt werden. Neben der Ebcdic-ASCII-Umsetzung sollen gepackte Daten, negative Werte und Zahlen mit Dezimalkomma ordnungsgemäß transferiert werden. Weiterhin muß der Benutzer per Menü bestimmen können, für welche Anwendungen er die Daten aufbereitet haben möchte (Lotus, Framework, Multiplan).

4. Direktes Füllen der elektronischen Formulare

Die mächtigsten Mikro-Anwendungen sind, wie schon erwähnt, sogenannte elektronische Formulare. Eine integrierte Host-Mikro-Verbindung muß in der Lage sein, die Anwendungen Lotus, Multiplan, Framework direkt zu füllen. Das heißt im Klartext: Der Anwender bestimmt, wo im Mikro-Formular Host-Daten plaziert werden sollen. Die Daten werden dann direkt vom Host in die vordefinierten Plätze gestellt.

Alle genannten Instrumente sind in der /34-, /36-, /38-Welt bereits verfügbar. Die neuen Konzepte forcieren ein Umdenken innerhalb der DV- und Fachabteilungen. Man spricht mehr und mehr nicht nur von Dateien und Daten, sondern von Informationen. Die intelligente Verbindung zwischen Host und Mikrocomputer ist mehr als ein File-Transfer.

*Frank Riemann ist Geschäftsführer der Riemann Consultig & Company GmbH.