[Contrib] [Chalisti] [07]    UNIX an der TUK/IF

UNIX an der TUK/IF Versuch einer Selbstdarstellung TU Karl-Marx-Stadt Sektion Informatik Guenther Fischer und Matthias Clausz Getting started 1982 - unsere Sektion hatte keine eigenen Studenten (Eine Sektion ohne Studenten ist wie ein vertrocknender Baum) - waren wir wohl mehr eine Dienstleistungseinrichtung (im Bereich der Ausbildung und rechentechnischen Versorgung) fuer die gesamte Hochschule. Unsere rechentechnische Basis bestand aus 2 ESER I-Anlagen (alias IBM 360). Wir hatten entgueltig den Sprung vom DOS zum OS geschafft und mit etwas Druck die Nutzung von TSO durchgesetzt - unser damaliger Wahlspruch lautete "TSO macht alle froh". Wir waren auch gerade dabei, uns von der Assembler-Programmierung zu loesen. Der Zufall Eines Tages schwirrte uns dann ein Magnetband ins Haus, das fuer den IBM-Alias zunaechst unverstaendliches Wirrwar enthielt. Nach Analyse des Hex-Dump war es nicht mehr so schwer, den ASCII-Code und die 512-Byte-Blockung zu erkennen. Auch wenn man noch nicht weisz, dasz es sich um das tar-Format handelt, ist man schnell in der Lage, ein Druckprogramm zu schreiben. Was dann dort entschluesselt auf Papier zum Vorschein kam (Unser Drucker hat nur Groszbuchstaben und eingeschraenkte Sonderzeichen a la IBM-Urzeit), war noch kryptisch genug. Die Kommentare und README's luefteten dann das Geheimnis. Das ganze sollte eine Programmiersprache (C) sein und der Name UNIX tauchte gelegentlich auf. Literaturrecherchen brachten dann bald Licht ins Dunkel. Es fand sich sogar ein bis dahin in der Sektion unbeachtetes Buch von Kernigan&Ritchie "The C Programming Language". Die Idee, ein Betriebssystem in einer hoeheren Programmiersprache zu schreiben und das gleiche Betriebssystem auf verschiedenen Rechnern zu betreiben, begeisterte uns sofort. Umfangreiche Literaturrecherchen, eine Arbeitsuebersetzung des C-Buches und eine Implementation des C-Praeprozessors cpp fuer unser System-Pascal (unser erster Versuch als Alternative zu Assembler) machten uns schnell in der UNIX-Szene der DDR bekannt (Unter Blinden sind die Einaeugigen Koenige). So lernten wir auch die anderen UNIX-Einzelkaempfer kennen: die Brueder Froehlich (ZKI und LfA Berlin), die Kollegen vom ZfT KEAW Berlin und der TH Ilmeneau sowie eine kleine Truppe bei Robotron Dresden. Wie strickt man einen C-Compiler Durch den cpp (umgeschrieben in eine andere C-aehnliche Sprache) ermutigt, machten wir uns an die Portierung des C-Compilers selbst. Da uns keine C-Umgebung auf irgend einem Rechner zur Verfuegung stand, waehlten wir nochmals den gleichen Weg: Abschreiben des C-Quelltextes mit Uebersetzung (im Kopf) in eine andere Sprache. Nach endlicher Zeit (etwa 3 Monate) entstand ein C-Compiler, der PDP/11-Assemblercode erzeugte. Die folgende Etappe war fuer uns als Compiler-Laien etwas komplizierter. Wir muszten den Codegenerator ueberzeugen, unseren IBM 360-Assemblercode auszuschwitzen, und gut sollte der erzeugte Code auch noch sein. Bis zum ersten Hello world auf dem Bildschirm ging es nach ersten Gehversuchen recht schnell. Nach etwa 4 Monaten gelang es, den C-Compiler mit sich selbst zu uebersetzen. Natuerlich war es erstmal wieder nur PDP/11-Code, der raus kam, aber von da an konnten wir in C denken. Die fuer die Codegenerierung notwendigen Aenderungen muszten nachgezogen werden. UNIX zum ersten ... Besonders die Beziehung zum LfA haben wir dann weit ausgebaut, da die dortigen Arbeiten an PSU unseren Moeglichkeiten am besten entsprachen. PSU war als Subsystem unter OS geplant. PSU ist eine Art UNIX mit eingeschraenkten Moeglichkeiten - insbesondere das Mehrprozeszkonzept wurde nur sequentiell simuliert. Das erste DDR-UNIX war also ein Stapelsystem, und es war in Assembler implementiert. Als TSO-Haie wollten wir natuerlich die Dialogmoeglichkeiten nicht missen und haben dann die optimale Anpassung der PSU ans TSO mit Rat und Tat unterstuetzt. Nach Einfuehrung der PSU stellten wir unseren Compiler sofort in diese Umgebung - die erste Version lief noch unter OS. Auch im Compilerumfeld arbeiteten wir dann eng mit dem LfA zusammen. Die Masse der UNIX-Werkzeuge konnte mit unserem Compiler in die PSU eingebracht werden. Dazu gehoerten natuerlich auch ein paar Spiele. So erfreute sich wump ("Hunt the wumpus") groszer Beliebtheit - im Zeitalter der Grafik kennt das wohl heute keiner mehr. Auch andere Uni's und Hochschulen haben sich an Portierungen beteiligt und uns damit natuerlich viele Compilerfehler nachgewiesen. Ein groszes Kuckucksei hatten wir uns (oder besser das LfA) dadurch ins Nest gelegt, dasz die PSU im EBCDIC-Code (der IBM-typische 8-Bit-Code) dachte. Einige Portierungen (z.B. nroff) erforderten dadurch wahre Kunststuecke. Unsere Linie begann Fruechte zu tragen: - die Studenten und Mitarbeiter konnten im Stapel und im Dialog mit den gleichen Werkzeugen arbeiten, - OS und TSO waren nicht mehr sichtbar, - wir konnten schon, was die Umgebung selbst betraf, fuer die Zukunft ausbilden. UNIX zum zweiten ... Parallel zu unseren PSU-Aktivitaeten betrieben wir stundenweise ein UNIX Version 7 auf einem Fremdrechner (alias PDP/11-20), um ein paar "echte" UNIX-Erfahrungen zu machen. Spaeter betrieben wir 2 solcher Rechner an unserer Sektion, die dann relativ reibungslos in Ausbildung und Forschung eingebunden werden konnten. UNIX zum dritten ... Eine neue Situation ergab sich, als unsere 2 360-iger durch 370-iger ausgetauscht wurden. Unser Ziel war jetzt, ein richtiges UNIX auf den Rechner zu bekommen. Eigene Entwicklungsarbeiten, viel Enthusiasmus und ein paar glueckliche Zufaelle versetzten uns in die Lage, innerhalb weniger Monate ein UNIX-System einzufuehren, das wir vollstaendig mit Quellen in der Hand hatten, das all unsere peripheren Geraete unterstuetzte, das auch "standalone" (also ohne VM) lauffaehig war, und fuer das eine vollstaendige deutschsprachige Dokumentation vorlag. In dieser Phase wurden wir aktiv von der TH Leipzig und der FSU Jena unterstuetzt. Die damit verbundene Bereitstellung von etwa 30 UNIX-Terminals brachte uns ein gutes Stueck in Ausbildung und Forschung voran. Allerdings ist unser sogenannter Groszrechner mit 0.5 MIPS oft ueberfordert und man musz manchmal etwas Geduld aufbringen. Auf dieser Basis wurden eine Vielzahl von Entwicklungen realisiert: - ein Jobverwaltungssystem mit dem Ziel, in der Nacht eine Jobabarbeitung zu realisieren - die Dialogmoeglichkeiten reichten bei weiten noch nicht aus, um alle Praktikumsanforderungen zu erfuellen, - verschiedene Sprachsysteme: Pascal, Modula 2, Lisp, Prolog, C, C++ (teils Portierungen, teils Neuentwicklungen), - eine Vielzahl technologischer Hilfsmittel. Inzwischen waren die 8-Bit'er da Diese Systeme, mit einem CP/M-Alias betrieben, sollen nur erwaehnt werden, weil sie als Ausbildungsbasis mit Turbo-Pascal, Datenbank- und Textverarbeitung bis heute als stabile Arbeitstiere genutzt werden. 8 + 8 = 16 == P8000 Eine deutliche Entkrampfung unserer Rechnermisere brachte der Einsatz mehrerer P8000-Systeme (etwa 15 Terminals). Diese Rechner auf Basis Z8000 werden mit dem UNIX-Betriebssytem WEGA betrieben. UNIX == UNIX ? prima : weniger prima Spaetestens hier war klar: Auf allen moeglichen Rechner UNIX (die 8-Bit'er ausgenommen) zu betreiben, ist sehr vorteilhaft, aber die UNIXe koennen auch sehr verschieden sein. VMX (unser 370-iger System) entspricht etwa Version 7 und WEGA soll System-III-kompatibel sein. Als leidenschaftliche Sammler von UNIX-Literatur verfolgten wir natuerlich alle Aktivitaeten von /usr/group ueber SVID und X/OPEN bis POSIX interessiert. DDR-UUG (EAG) "GUUG und EAG: Warum machen wir hier nicht die Einheit von unten?" Alle DDR-UNIX-Entwickler hatten sich unter anderem schon fruehzeitig eine einheitliche Dokumentation fuer die verschiedenen Systeme auf die Fahnen geschrieben. Vor 2 Jahren begannen wir eine solche Dokumentation fuer Systemrufe und Bibliotheksfunktionen zu erstellen, die an X/OPEN bzw. SVID angelehnt war, also in etwa System V Release 2 entsprach. Spaeter kam auch die Kommandobeschreibung (man1) hinzu. In den konkreten Systemen sollte, wenn moeglich, eine solche standardisierte Schnittstelle realisiert werden. Da, wo das schwer moeglich war, wollten wir wenigstens die Abweichung vom Standard in der Dokumentation ausweisen. Fuer 2 Systeme (VMX und MUTOS 1835) haben wir das recht weit getrieben. Auch wurde unsere Dokumentation ueber die EAG anderen bereitgestellt und diente fuer weitere Systeme als Vorbild. Der Flop Bei MUTOS 1835 handelt es sich uebrigens um eine UNIX-Entwicklung, die wir fuer einen AT-kompatiblen von Robotron gemacht haben (als Auftragsentwicklung). Da der Rechner bis heute nicht produziert wird, musz man das ganze wohl als Flop betrachten. UNIX bei uns heute ... Auch die Beschaeftigung mit X und ET++ auf AT/286 ist wohl nur als Voruebung fuer bessere (hardware-) Zeiten zu betrachten. Schon seit ueber einem Jahr sollten die Entwicklungen dann in Richtung 386 gehen. Bis heute ist es uns leider nicht gelungen, wenigstens einen solchen Rechner aufzutreiben. Inzwischen ist bei uns noch ein K1840 (VAX/11-780-Alias) installiert worden, der mit dem dort ueblichen UNIX-Betriebssystem MUTOS 1800 (BSD laeszt grueszen) betrieben wird. Zur Zeit laufen noch Arbeiten, unser VMX auf den Stand System V Release 3 zu heben. Die Bedeutung dieser Arbeiten liegen aber wohl mehr in der Projektarbeit von Studenten. .. und morgen? Mit groszem Interesse betrachten wir das GNU-Projekt, die laufenden Arbeiten an X/OPEN und von OSF, besonders jetzt, wo AIX durch Mach ersetzt werden soll. OSF soll ja auch an Partnern im universitaeren Bereich interessiert sein!? Da sind wir auch schon bei unserem Problem: Wie geht es in Zukunft im Bereich der Forschung bei uns weiter? Bisher saszen wir hinter einer 2-fachen Mauer - die eine selbst errichtet und nun endlich zerschlagen, die zweite vom Westen (z.B. COCOM) - auch diese broeckelt. Das Hinterherlaufen der letzten Jahre war aus der Not geboren - unser Handwerk haben wir dabei gelernt. Jetzt brauchen wir eine Absicherung unserer zukuenftigen Forschungsarbeiten, die uns Freizuegigkeit bei der Beschaffung von Hard- und Software, die Teilnahme an internationalen Veranstaltungen, den Netzzugang und Literatur ermoeglicht. Ob das nun durch Beteiligung an Forschungsthemen anderer Einrichtungen, durch Industrieforschung oder wie auch immer geschieht, ist uns fast egal - wir wollen nur soweit wie moeglich unsere Zukunft mitgestalten und nicht auf das warten, was da mal von "oben" kommt. Den letzten Satz kann man auch politisch sehen. Autor: Guenther Fischer (gf@tu-k-ddr.cs.tu-berlin.de) ------------------------------------------------------------------------------

[Contrib] [Chalisti] [07]    UNIX an der TUK/IF