Websalon

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)
------------------------------------------------------------------------------