Nicht nur im Bereich der PCs etabliert sich Unix auf breiter Basis. Bereits seit einigen Jahren findet das System Eingang in die Domäne der früheren Mini- oder MDT-Rechner und der seit kurzer Zeit aktuellen Abteilungsrecher.
Und das aus gutem Grunde. Wurden doch gerade in der letzten Zeit an den Abteilungsrechner sehr hohe Anforderungen bezüglich Allround-Flexibilität gestellt. Dort, wo früher einfache herstellerspezifische Lösungen eines Problems ausgereicht haben, bilden heute gerade diese eine Sackgasse.
Der Abteilungsrechner - dieser Begriff entstand vor nicht allzu langer Zeit - hat nämlich eine Universalfunktion. Er steht entweder als Verbindungsglied zwischen Großrechner und PC, oder er soll als Stand-alone-System verschiedene Aufgaben erfüllen. In beiden Fällen sind die Anwendungen sehr vielfältig:
- als Entwicklungsrechner für allgemeine Software-Entwicklung,
- als Werkzeug für die Software-Lösungen der täglichen Aufgaben (Technisch-Wissenschaftlich),
- als Werkzeug für Bürotätigkeiten (Statistik, Tabellen, Text), - als Anwendungssystem für dedizierte Komplettanwendungen (zum Beispiel FiBu, Lohn, Lager etc.).
Mit der rasanten Entwicklung der Kommunikationsfähigkeiten und -Technologien, mit der genauso enormen Entwicklung der Programmiersprachen und Entwicklungstools, mit dem immer stärker ans Tageslicht tretenden Wünschen der Anwender nach nach offenen Systemen und (Leistungs-) Wachstumspfaden haben die meisten Anbieter althergebrachter mittlerer Systeme nicht Schritt halten wollen oder können - oder einfach die Zeichen der Zeit verschlafen.
Bei solchen herkömmlichen Systemen sieht es so aus, daß sie eine (einzige) Gemeinsamkeit haben, nämlich die, daß sie in nichts gleich sind. Außer daß man sich einigermaßen an die SNA/3270-Kompatibilität gehalten hat, haben diese Hersteller alle anderen - in der realen Welt des Anwenders nun einmal existierenden - Sytemwelten außer der eigenen genauso außer Acht gelassen wie etwaige Kundenwünsche nach einigermaßen funktionierenden Brücken zwischen diesen. Wie soll ein Systemhaus, geschweige denn ein Enduser etwas bewerkstelligen, wozu selbst der Systemhersteller nicht imstande ist?
Betriebssystemerweiterungen, die neuerdings angeboten werden, wie etwa eine integrierte Datenbank, sind keine Lösung: Sie erhöhen die bereits vorhandene Herstellerabhängigkeit noch.
Das Problem der bisherigen Rechner der Abteilungsrechner-Kategorie war, daß jeder Anbieter/Hersteller seine eigene Systemwelt geschaffen hatte. Die dort herrschenden Standards werden nicht von der Universalität der Einsatzmöglichkeiten bestimmt, sondern durch die Größe des Herstellers beziehungsweise der Verbreitung seines Systems. Damit Hand in Hand geht die vollkommene Abhängigkeit des Benutzers vom Hersteller und seinen Entwicklungstrends sowie von dessen Hardware- und Software-Komponenten. Die Freiheit des Anwenders/Entwicklers besteht dann meist darin, etwa benötigte und nicht vom Hersteller angebotene Software selbst zu entwickeln - oder ohne sie auszukommen.
Der nächste Stolperstein liegt in der Flexibilität der Hardware-Erweiterbarkeit. Sehen wir etwa davon ab, daß die maximale Massenspeicherkapazität und die Anzahl der Arbeitsplatzanschlüsse zwar meistens schon bei der - Anschaffung durch die Systemklasse vorgegeben sind, so hat der Kunde in einer Proprietary-Welt darüber hinaus auch nicht die Möglichkeit, etwa Festplatten, Streamer oder sonstige Laufwerke mit Stadardschnittstellen einzusetzen, sondern muß sich immer an die herstellereigenen Komponenten halten. Das gleiche gilt für Peripherie wie Terminals und Drucker.
In den wenigsten Fällen wird der Benutzer einen kostengünstigen
Drucker mit Centronics- oder V.24-Schnittstelle oder ein Low-cost-V.24-Terminal anschließen können, sondern muß sich der von seinem Proprietary-Lieferanten angebotenen Geräte bedienen, die eine meist teurere Spezialschnittstelle enthalten.
Natürlich leidet unter diesem Problem die allgemeine Kommunikationsfähigkeit. Verbindungen zur Außenwelt, etwa per Modern, X.25, X.400, oder Btx, Telex/Teletex, Fax benötigen nicht minder komplizierte und teure Anschluß-Hardware und -Software.
Durch Unix als systemunabhängiges Betriebssystem-Standard eröffnen sich sowohl dem Entwickler als auch dem Benutzer neue Perspektiven.
Die vor einigen Jahren noch bestehenden Unterschiede der verfügbaren Unix-Systeme, die gern von den MDT-Anbietern herausgestellt wurden, um die Unsicherheit der Anwender zu verstärken, die aber in Wirklichkeit nicht so gravierend waren, sind mittlerweile eingeebnet worden.
Zu diesem Trend trug die Kostenentwicklung genauso bei (die Entwicklung eigener Derivate wären ins Unermeßliche gestiegen, dabei tut es ein Original-System V von AT&T mit BSD-Erweiterungen ebenso) wie im Laufe der Zeit ins Leben gerufene Standardisierungsgremien wie SVID, Posix, X/Open und ANSI (Sprachelemente von "C"). Die Standardisierung innerhalb der diversen Unix-Varianten ist heutzutage soweit gediehen, daß man guten Gewissens feststellen kann, daß ein Unix System V immer die gleiche Standardwelt beinhaltet.
Der Vorteil von Unix, gerade in dieser Systemgrößenordnung, ist die Verfügbarkeit auf den unterschiedlichsten Prozessoren und Systemarchitekturen. Das Spektrum reicht von den 80X86-Prozessoren über Motorolas 680X0-Familie, NS 320XX, WE 32000, diverse RISC-CPUs (Sparc, Mips) bis zu herstellereigenen Zentraleinheiten wie PDP, VAX, DG, Prime GS und IBMs /370. Der Prozessor bleibt völlig im Hintergrund, die Umgebung ist immer gleich. Bei der Software-Entwicklung mit der Unix-Standardsprache C ist bei einer einigermaßen disziplinierten Schreibweise ein genauso hohes Maß an Gleichheit zu erzielen. Das einzige wirklich relevante Problem, das allerdings nichts mit Unix zu tun hat, sondern mit C, ist die Byte-Order innerhalb einer Integerzahl, die CPU-abhängig ist.
Der aus diesen Tatsachen resultierende Vorteil liegt in der möglichen flexiblen Anpaßbarkeit des Systems an die Anwendung in einem weiten Bereich. Das bedeutet eine hohe Flexibilität und Mobilität des Benutzers. Er kann sehr kostengünstig entwerfen, testen, ausprobieren. Das ist aber nur die Spitze des Eisbergs.
Vielmehr müssen wir die sekundären und tertiären Effekte und Ergebnisse berücksichtigen, die aus der Unix-Philosophie resultieren und die zu einer wahren Explosion von Unix-Systemen (Software und Hardware) geführt haben. Die meisten Software-Neuentwicklungen heute werden zunächst auf einem Unix-System durchgeführt. Nicht ohne Grund: Die Erweiterungsmöglichkeiten eines Unix-Systems sind im Rahmen der Systemarchitektur enorm.
Das beginnt bei der Systemspeichererweiterung. Bei Standard-Bus-Systemen (Multibus, VME-Bus, Q-Bus, AT-Bus) ist diese Erweiterung durch Stecken eines RAM-Boards genauso einfach durchzuführen wie bei herstellereigenen Systemen (Sun, 3B2, TI etc.), für die entsprechende Erweiterungen von Zweitanbietern angeboten werden.
Bei Massenspeichern sieht die Situation nicht anders aus. Standardschnittstellen sind da normal und üblich (ESDI, ST-506, SCSI, SMD/ESMD). Bildschirme und serielle Peripherie stellen unter Unix keine Probleme dar. Ebenso verhält sich die Situation im Hinblick auf Kommunikationsfähigkeit (V.24, X.25) oder auch SNA, 3270, RJE, 2780, TCP/IP etc.
Das gleiche gilt für den Datenaustausch. Ob Band, Streamer oder Floppy, über das Tarformat sind Daten leicht austauschbar. Sollte dieser Weg einmal nicht möglich sein, steht immer die V.24 zur Verfügung. In der MDT wäre solches undenkbar.
Die vorhandenen Sprachen spielen ebenfalls eine wichtige Rolle. In diesem Bereich besteht eine hochinteressante Diskrepanz: Auf der einen Seite herstellereigene Systeme, die eine Sprache stark favorisieren (zum Beispiel RPG II, Comet, Basic, Fortran) und solche, die überhaupt nicht in der Lage sind, eine Alternative anzubieten oder sich zumindest sehr schwer tun, eine weitere Sprache zu realisieren (zum Beispiel PL/1 für AS/400).
Auf der anderen Seite ein "Universalgenie" für das fast spielerisch leicht das Sprachspektrum erweitert wird.
Nicht nur, daß sämtliche EDV-Standardsparchen wie Pascal, Fortran, Basic und Cobol unterstützt werden. Auch Gebilde wie PL/1 oder RPG II sind von kompatibel zu ihren Originalen unter Unix erhältlich. Ganz zu schweigen von neueren Sprachen wie Prolog, Lisp oder Modula und Forth, deren Implementierungen auf herstellereigenen Systemen lange gesucht werden müssen. Die Ursache ist einmal die Tatsache, daß heute eigentlich alle Compiler selbst in C geschrieben sind, damit hat man auch die gleiche Entwicklungsumgebung. Die zweite Ursache liegt in den unter Unix verfügbaren Tools wie MAKE, LEX, AWK, YACC, SCCS.
Während für die Anwendungsentwicklung meistens nur die beiden letzteren eingesetzt werden, sind die übrigen für den Compilerbau äußerst wichtig. Gerade mit deren Hilfe lassen sich modulare Compiler bauen, bei denen das Frontend (die Hochsprache) vom Backend (dem produzierten Maschinencode) unabhängig ist. Standardisierte Systemaufrufe und Schnittstellen runden das Gesamtbild ab. Damit ergibt sich unter Unix eine Welt des Compilerbaus, die in Systemen wie /3X oder Niros schier unvorstellbar war.
Was aber ist die Auswirkung? Alle Beteiligten, vom Hersteller über Systemhäuser bis zum Anwender haben die einmalige Gelegenheit, ihre MDT/Mini-System-Anwendungen unter Unix ohne oder mit geringen Modifizierungen zum Laufen zu bringen. Durch die Flexibilisierung des Compilerbaus sind auch Cross-Compiler entstanden. Diese ermöglichen zum Beispiel den Einsatz eines Rechners als Entwicklungswerkzeug für andere Systeme.
Und, das ist ebenfalls immens wichtig, konnten unter Unix und dessen Werkzeugen äußerst hilfreiche Tools wie Quellcode-Übersetzer entstehen. Der Anwender hat somit die Möglichkeit, seine in Cobol oder Fortran, aber auch in Pascal und HP-Basic geschriebenen Programme von seiner /370- oder VMS-Welt nach C zu übersetzen und nach Unix auszulagern und damit nicht nur zu vereinheitlichen, sondern zum Teil zu besserem Zeitverhalten zu verhelfen und richtig portabel zu machen.
Das Unix-System ist prädestiniert für komfortable und effiziente Software-Entwicklung. Das Resultat sind System-Entwicklungstools unter Unix, die einmal sehr schnell entwickelt werden, und andererseits da die meisten von ihnen in der standardisierten Systemumgebung entwickelt werden, hervorragend portiert werden können. Die schnellere Systementwicklung ermöglicht eine Senkung der Entwicklungskosten und damit auch der Produktkosten. Gleichzeitig erhöht sich die Portabilität des Produktes. Mit Hilfe des Einsatzes dieser Werkzeuge wird auch die Wartbarkeit der Software-Produkte verbessert.
Diese Tools erstrecken sich von Masken- und Menue-Bibliotheken über I/0-, mathematische und graphische Bibliotheken bis zu richtigen Applikationsgeneratoren, zur interaktiver Anwendungsentwicklung mit transparenten Datenbankschnittstellen.
Eine weitere Stufe der Tools stellen Quellcode-Generatoren dar. Mit diesen kann ein System entwickelt werden von der Maske bis zur Datei, ohne eine einzige Zeile Programm zu schreiben. Deren Portabilität wird durch die Standardspache C und deren Bibliotheken ermöglicht.
Es zeichnet sich übrigens ein weiterer Trend in der Software-Entwicklung unter Unix: Das Objekt-orientierte C, mit dessen Möglichkeiten der Daten- und Funktionsklassen-Definitionen sich sehr schnelle Entwicklungen oder Änderungen realisieren lassen.
Mit den komfortablen Entwicklungstools unter Unix gehen bereits vorhandene Standard-Software-Pakete Hand in Hand. Gerade in diesem Bereich vergrößert sich das Angebot der Software-Lösungen unterschiedlichster Art sehr rasch. Das Angebot reicht hier vom Textsystem über Spreadsheet bis zu Grafikpaketen. Büro-Systeme, die alle diese Teile in sich vereinigen, sind genauso zu finden wie Projekt-Verwaltungssysteme oder KI-Systeme.
Auf den meisten Systemen laufen fast alle Datenbanken
Eine Klasse für sich bilden dabei die Datenbanken, über die sich lapidar feststellen läßt, daß auf den meisten Systemen praktisch alle Datenbanken laufen. Die Lösungen können den Anforderungen und dem Geldbeutel gemäß ausgerichtet werden. Gerade der Einsatz von Unix hat die enorme Verbreitung und Verbesserung der Datenbanken gebracht. Das ist die Basis für anwenderspezifische Entwicklungen oder auch standardisierte Produkte im kommerziellen Bereich.
Ein Abteilungsrechner wird meistens unmittelbar mit der DOS/ PC-Welt konfrontiert, mit der er zu integrieren ist. Die 386-basierenden Rechner bilden dabei wegen der möglichen DOS-Emulation direkt im System eine Klasse für sich. Aber auch für andere Systeme liegen Standardlösungen auf Basis von Ethernet vor. So kann jeder PC mit jedem Unix-Rechner gekoppelt werden: entweder über TCP/IP mit allen dort verfügbaren Diensten oder über ein PC-Interface, bei dem der Unix-Rechner als Server fungiert.
Gerade das Beispiel des Abteilungsrechners demonstriert die Leistungsfähigkeit und Flexibilität des dafür außergewöhnlich gut geeigneten Unix-Systems. Der Anwender hat auf Grund des breiten Angebots die Möglichkeit, seine DV-Welt seinen Wünschen anzupassen und zu vereinheitlichen, ohne faule Kompromisse eingehen zu müssen.