Unix setzt sich im Bereich unterhalb der Mainframes und oberhalb der PCs durch, das ist nicht mehr zu bezweifeln. Und was auch immer und wie bald Unix ablöst: Software und Daten, die heute und morgen unter Unix produziert werden, sind mit Sicherheit in das portierbar, was danach kommt. Schöne neue Unix-Welt, aber was ist mit solch nützlichen Sachen wie Spreadsheets und Textverarbeitung, Desktop Publishing, Grafik und die arbeitsplatzbezogene Datenbank?
Diese Anwendungskonzepte sind im Unix-Rahmen noch interessanter, durch die Kombination mit Diensten, die Arbeitsplätze integrieren, sprich E-Mail und Konferenzplanung, um die potentiell wirkungsreichsten anzusprechen. Anders gesagt: Wie steht es mit dem verfügbaren Angebot an dem, was man unter "Büroautomation" oder, meist im gleichen Sinn gebraucht, "Bürokommunikation" rubriziert?
Wenn man Leute fragt, die mit dem umgehen, was wirklich zu haben ist, dann ist das Ergebnis mager. Gemeint sind die Verkäufer; bei Entwicklern hört man natürlich vorwiegend von dem, was übermorgen anwendungsreif sein mag. "Unter Unix" haben solche Sachen im Moment offenbar nur zwei Anbieter, der eine davon ausschließlich für Systeme der kleineren Klasse bis 64 Arbeitsplätze, der andere allerdings für die "volle Power" mit 8 MIPS und 128 direkt oder 600 im Netz angeschlossenen Arbeitsplätzen. Diese beiden sind Siemens und ICL.
Kompromiß: Anleihen bei bewährten PC-Funktionen
Alle anderen kaprizieren sich auf einen Ausweg - der so schlecht nicht ist, aber eben auch nicht die elegante Lösung. Elegant heißt hier: Einheitliche Organisation, mehr Sicherheit für die Unternehmen, daß an den Arbeitsplätzen nicht willkürlich mit Computerkraft und Daten umgegangen wird. Der gängige Weg ist der, PCs anzuschließen und über den Unix-Rechner lediglich die integrierenden Funktionen, nämlich die übergreifende Datenbank, E-Mail und Konferenzplanung beziehungsweise Kalenderabstimmung laufen zu lassen. Der Unix-Zentral- oder Abteilungsrechner fungiert bei dieser Methode als Fileserver für die angeschlossenen PCs.
Nixdorf hat, nur als Beispiel, eine interessante Lösung für die Aufgabe, aus der Terminalfunktion des PC Informationen vom jeweiligen zentralen Rechner in die MS-DOS-Umgebung zu übernehmen, und zwar ohne den Umweg über den Filetransfer. Dazu wird der Inhalt des Bildschirmspeichers anhand entsprechener Gateway-Software in die gewünschte PC-Standardsoftware übertragen.
Im Bereich des Datenbankmanagements gibt es Systeme, die auf dem Zentralrechner und auf dem MS-DOS-PC die gleiche Oberfläche haben. Wenn das auch noch keine identische Behandlung der Daten innerhalb beider Systeme bedeutet, so ist doch ein entscheidender Anwenderkomfort gegeben.
Als zusätzliche Möglichkeit sind solche PC-Anbindungen mit Sicherheit sinnvoll. Zum Beispiel sollten bestehende PC-Anwendungen unterstützt werden. Bestimmte Arbeitsplätze, vor allem solche von besonders dafür qualifizierten Mitarbeitern, sollten mit eigener Computer-Power ausgerüstet bleiben oder werden. Es gibt auch Anwendungen, die den ständigen Austausch mit dem Zentralsystem nicht brauchen und gleichzeitig besonders Rechnerzeit- und durchsatzintensiv sind, wie zum Beispiel Desktop Publishing oder gar CAD - typische Workstation-Einsätze also. Bei solchen Anwendungen ist auch zu bedenken, daß der Bedarf an Kommunikation so gut wie immer dateibezogen ist: Man macht einen Job auf dem eigenen Arbeitsplatzrechner fertig, ehe er übertragen wird - im Filetransfer. Solche Jobs sind sinnvoll über PC/Workstations zu erledigen.
Aber das ist ein Teilaspekt. Auf Dauer sind für die Büroautomation als Ganzes Lösungen gefordert, die von der Mehrplatzfähigkeit Gebrauch machen. Das gilt für die übergreifenden Datenbanken und ebenso für dedizierte Programme wie die dafür immer als Beispiel herhaltende Materialwirtschaft - auch Konferenzplanung übrigens, die auch eine Art Materialwirtschaft ist. Das sind alles Dinge, die auf "Record Locking" beruhen, dem Sperren des Datensatzes, solange jemand mit ihm arbeitet. Die satzweise Übernahme von Daten und Texten in die Textverarbeitung muß möglich sein, wenn sie entsprechend integriert und integrierend angewandt werden soll. Und: "Möglich" muß heißen, daß sie auf den speziellen Anwendungsfall programmiert werden kann, also automatisch vor sich geht.
Integration von dedizierten Programmen und Diensten
Ein Beispiel dafür gibt der Landschaftverband Westfalen-Lippe, Träger einer Reihe von Krankenhäusern, der mit dem einen für größere Hardwaresysteme in deutscher Sprache verfügbaren Konzept ICL Officepower einen Teil seiner Programmierarbeit sparen will. Dort sollen für Abrechnungen mit den Krankenkassen Informationen aus der Datenbank automatisch in die Textverarbeitung eingebaut werden - normalerweise ein Fall für herkömmliche Programmierung mit allen Beschränkungen für den Textumfang und dem üblichen, hohen Arbeitsaufwand. Von der Büroautomation/-kommunikation erhofft man sich mehr Komfort und weniger Aufwand.
Das BK-Paket, das direkt unter Unix läuft, ist ursprünglich von CCI entwickelt worden, aber von ICL für den deutschen und andere europäische Märkte angepaßt und ergänzt worden. CCI ist gegenwärtig ein erfolgreicher OEM-Lieferant sowohl auf dem Hardware- wie auf dem Software-Sektor. Die Hardware ist im Leistungsbereich der Superminicomputer angesiedelt: Die bei ICL ursprünglich "CIan" - neuerdings in Fortführung einer "kleineren" Modellreihe DAS 400 und 500 - genannten Rechner bringen, wie erwähnt, bis zu 8 MIPS und bedienen bis zu 128 Anschlüsse.
Der Club der weiteren Unix-Anbieter wird sicherlich in absehbarer Zeit mit ähnlichen Angeboten herauskommen. Um so interessanter ist es, sich anzusehen, was schon heute in der Art verfügbar ist.
Basis dieses Bürokommunikations-Konzepts ist wie gesagt die mehrplatzfähige Anlage unter Unix. Das umfaßt eine Textverarbeitung, die zum Beispiel vom Krankenhausträger in einer umfassenden Marktuntersuchung als allen anderen überlegen beurteilt wurde. Ferner gibt es eine Tabellenkalkulation (Basis Access 20/20), Konferenz- und Kalenderplanung, eine Arbeitsplatzdatenbank, die die Abgabe und Übergabe von Sätzen an die übergreifenden, relationalen Datenbanken wie Ingres, Oracle oder Informix sehr elegant handhaben läßt und natürlich E-Mail. Es gibt dann noch eine Reihe von weiteren Diensten, deren Relevanz sich wohl erst aus der Praxis heraus beurteilen lassen wird.
Die verschiedenen Anwendungen haben eine einheitlich angelegte Oberfläche ("Uniguide") mit gleicher Bedeutung der Funktionstasten. Die Arbeitsplatzdatenbank hat übrigens etwas, was bei allen großen Datenbanken auswärtiger Provenienz erst noch kommen soll: deutsche Umlaute (sie sortiert auch danach). Die Tabellenkalkulation hat saubere Schnittstellen zu anderen, auch dediziert geschriebenen Programmen. In einer Mehrplatzanwendung ist die Übernahme von Daten in andere Programme natürlich noch wichtiger als am Einzelplatz, obwohl die Abschottung der meisten Tabellenkalkulationen oder die zumindest sehr umständliche Datenübernahme eigentlich auch dort schwer zu akzeptieren ist.
Schnittstellen, Datensicherheit und angepaßte Formate
Zu einem BK-System gehören selbstverständlich die Software-Schnittstellen zu den öffentlichen Diensten und nicht zuletzt zu PCs. Terminalfunktion zu Hostrechnern zum Beispiel als 3278-IBM-Bildschirm ist heute selbstverständlich, ebenso entsprechender Filetransfer. Auch Zugriffsregulierungen, sprich Datensicherheit und Datenschutz, sind inbegriffen.
Alle Dienste, zum Beispiel Konferenzplanung, funktionieren in lokalen wie in öffentlichen Netzen ganz so wie innerhalb der Mehrplatzumgebung eines einzigen Rechners. Ingres, Oracle und Informix sind netzwerkfähig und so auch die Arbeitsplatz-Datenbank. Lokal schließt man diese Unix-Rechner über OSLAN zusammen. Für die öffentlichen Netze ist das Bürokommunikations-Paket auf OSI-Empfehlungen aufgebaut. Ab Frühjahr 1989 wird das auf den X.400-Standard hinauslaufen, der im Augenblick zwar einen konkreten Orientierungsrahmen, aber noch keine Anwendungsrealität darstellt.
Bekanntlich umfaßt X.400 mehrere Kommunikationsschichten und lagert über den drei Schichten des X.25. Darauf wiederum baut ODA auf (Office Document Architecture). Es erweitert die Regulierungen von X.400 vor allem um Grafik und um Steuercodes für Formatierungen.
Die Zielsetzung von ODA ist, für gemischte Dokumente von Text und Bildern ein umfassendes neutrales Austausch-Format festzulegen, in das von jedem herstellerspezifischen Format übersetzt wird (pre-processing), um es über die Leitung zu schicken, damit es der andere Rechner wiederum in sein spezifisches Format übersetzt (post-processing). Dieses Austauschformat nennt sich ODIF (Office Document Interchange Format). Der Vorgang der beim ODA-Transfer abläuft, ist also im Prinzip ähnlich wie bei der bekannten ASCII-Datei im DOS, korrekt, der DOS.TXT-Datei. Nur soll eben ODA im Gegensatz zu der beschränkten Regulierung der ASCII-Datei wirklich dafür sorgen, daß ohne menschliches Dazutun bzw. Korrigieren auf dem fremden Bildschirm genau das wieder zu sehen ist, was man auch auf dem eigenen hat.
ODA ist somit auf seinem Gebiet am ehesten mit der umfangreichen Regulierung für CAD-Datenübertragung, IGES, vergleichbar. Allerdings ist zu hoffen, daß ODA-Übertragungen, da wegen des Übergewichts der Texte denn doch nicht gar so komplex, wesentlich schneller gehen als im CAD-Bereich unter IGES. Sonst könnten die 1:1-Anpassungen, wie man sie von den eingeführten Textprogrammen her kennt, am Ende doch wieder die praktikablere Lösung sein. Heute sind sie zumindest nützlich, um Texte anderen Textprogrammen zuzuführen. Aus der Anwendungspraxis heraus nennen Anbieter folgende Beispiele für einen OSA-Einsatz: Übermittlung von Texten an eine Setzerei/Druckerei oder Datenaustausch mit den sich verbreitenden Laptops, die unter MS-DOS arbeiten.
Nachdem ODA 1987 erstmals demonstriert wurde, arbeitet man jetzt unter dem Kürzel "PODA 2" (Piloting of Office Document Architecture) daran weiter. Projektführer ist ICL, und weitere Mitglieder der Runde kommen aus fünf europäischen Ländern: Bull, SEPT und TITN aus Frankreich, OCE aus den Niederlanden, Olivetti aus Italien, das University College aus England sowie IBM, Siemens und Nixdorf aus Deutschland. Rund 36 Millionen Mark sind aus dem ESPRIT-Topf dafür vorgesehen.
Es wird noch viel entwickelt, angepaßt und reguliert. Wichtig für Entscheidungen heute ist jedoch, daß im "Unix-Club" schon jetzt im Hinblick auf Bestehendes und zu Erwartendes produziert wird. Auf jeden Fall werden Alleingänge außerhalb der OSI-Vereinbarungen, in deren Rahmen X.400 und ODA zu sehen sind, auf Dauer keine Chance haben - und deren Anwender auch nicht.