Datenbank-Entwicklung und Anwendung unter UNIX in der DDR Sehr geehrte Damen und Herren ! Auf der Einladung zur heutigen Veranstaltung finden Sie das Thema "Datenbank-Entwicklung und Anwendung unter UNIX in der DDR" und als Vortragende zwei Namen: Wenzlaff und Froehlich. Mein Name ist Froehlich, ich komme vom ZKI (Langform: Zentralinstitut fuer Kybernetik und Informationsprozess der DDR-Akademie der Wissenschaften), und ich bin bei dem gan- zen der Leidtragende, weil ich, nachdem ich aus einem Urlaub zurueckkam, mit der Aufgabe konfrontiert wurde, einen Vor- trag zu halten, der einzig auf meinen Kollegen Joerg Wenz- laff zugeschnitten ist. Nun gut, Herr Wenzlaff kann heute leider nicht unter uns sein, und ich werde, mit einigen Arabesken, das erzaehlen, was er zu berichten vorhatte. Bevor ich zum eigentlichen Thema komme, kann ich es mir nicht verkneifen, einen Ausflug in die Geschichte der Bechaeftigung mit UNIX in der DDR zu unternehmen, zumindest in dem Rahmen, wie mein Institut daran beteiligt ist. Auf der Suche nach einer Basis fuer ein zeitgemaesses Soft- ware Engineering Environment, bzw. nach einem reorganisa- tionsfreien Filesystem mit einer fast unbeschraenkten Zahl vor allem kleiner Files, haben Kollegen aus dem LfA (Leit- zentrum fuer Anwendungsforschung, der heutige Veranstalter) und dem ZKI mit der Untersuchung einer UNIX-Quelle begonnen, die in abenteuerlicher Form in unsere Haende geraten war. Das war Mitte 1981, als Zielrechner haben wir nur die damals noch ueberwiegend im Stapelbetrieb genutzten Robotron- Rechner 1040 und 1055 gesehen. Diese Anlagen sind den IBM- Machinen 360/50 bzw. 370/140 vergleichbar. Die UNIX-Quelle war ein Version 6 UNIX, so aus dem Jahre 1976/77, genauer gesagt, Kern-Quellen und Quellen zu C-Compiler, Assembler, Verbinder und eine fruehe Version des relationalen DB-Sys- tems INGRES aus Berkeley. Diese Quellen waren mit 'dd conv=ebcdic' in ein festes Format konvertiert worden, wobei leider auch alle Kleinbuchstaben in Grossbuchstaben und alle besseren Sonderzeichen in durch unsere Drucker nicht behandelbare Zeichen verwandelt wurden. Alle Informationen zu UNIX und C mussten wir aus dem 78er Bell Systems Technical Journal gewinnen, mehr Literatur war uns nicht zugaenglich, insbesonerde keine Literatur zu den pdp11, den Wirtsrechnern des Systems. Um es abzukuerzen, Ergebnis dieser ersten Untersuchungen war die PSU (Programmier-stuetzende Umgebung) des LfA fuer oben genannte Robotron Rechner, einsetzbar im Stapelbetrieb, unter TSO und CMS, ein heute nur noch leicht eingeschraenk- tes Mehnutzer-UNIX. Die erste Version der PSU lief schon im Sommer 1982. Die Arbeiten zur PSU wurden im wesentlichen vom LfA getragen, einige Hochschulen, insbesondere die TU KMStadt haben zeitweilig wertvolle Leistungen beigetragen, das ZKI hat nur in der allerersten Phase mitgewirkt. Wir konnten naemlich ab 1982 stundenweise auf einem Rechner, der der pdp11/34 ziemlich nahe kam, erste Erfahrungen mit einem Version 6 UNIX machen, das in binary Form in unsere Haende geraten war. Unsere Bemuehungen zielten auf einen selbststaendig vorzunehmenden Umstieg auf UNIX Version 7 ab, d.h., wir wollten zuerst einen V7-C-Compiler schaffen und dann schrittweise den V6-Kern aufbohren. Diese Arbeiten fanden einen natuerlichen Abschluss, als uns eine vollstaen- dige V7-Quelle in die Haende geriet, das war im Fruehjahr 1983. Diese Quelle wurde Ausgangspunkt fuer UNIX Aktivitae- ten bei Robotron, dort stellte man fuer einen pdp11/34 aehnlichen Rechner eigener Produktion in der Folge das V7 kompatible System MUTOS (Multi User Time-sharing Operating System) her, spaeter auch fuer IBM/XT vergleich- bare PC's. Robotron arbeitete, auch was die Dokumentationen anbelangt, eng mit der TH Ilmenau zusammen. Ich moechte hier gleich einschieben, dass der Kontakt zwischen allen mit UNIX befassten Gruppen in der DDR immer sehr eng und freundschaftlich war, unabhaengig ob sie in Hochschulen, der Akademie oder der Industrie (Robotron und EAW-Berlin) angesiedelt waren. Zu diesem Zeitpunkt, 1983, begannen auch im EAW Arbeiten zu einem auf dem Zilog Prozessor Z8001 basierenden Mikro- rechner, fuer den zuerst ein V7, spaeter System III kompa- tibles Betriebssystem, genannt WEGA, entwickelt wurde. Diesem Rechner, mit seinem UNIX System, ist es zu danken, dass es in der DDR nicht nur UNIX-Entwickler und Adaptierer, sondern auch eine ernstzunehmende Anwendergruppe gibt. Wobei, wenn ich mir so den bisherigen Verlauf unserer Histo- rie ansehe, sicher die Mehrzahl lieber IBM-PC's genommen haette, wenn sie sie haetten nur kaufen koennen. Ich moechte die Uebernahme von Amdahl's UTS durch die TU Karl-Marx-Stadt, unter dem Namen VMX seit einigen Jahren auf einigen Anlagen aehnlich IBM 370/..., hier wenigstens kurz erwaehnen, ebenso die Aktivitaeten meines Institutes zu einer nebenlaeufigen Entwicklung zum P8000 vom EAW, gemeinsam mit dem EAW betrieben (von dort die Hardware, von uns ein V7 UNIX, genannt MUTOS 8000). Letzteres ist nur dadurch interessant, das unsere Zielhardware ueber 256 KByte RAM und als externem Speicher ueber drei 8"-Floppylaufwerke mit insgesamt weniger als 750 kByte verfuegte. Und noch etwas, was charakteristisch fuer die Arbeitsbedingungen aller unserer Gruppen war und eigentlich noch ist: Fuer den vollstaendigen Transport (Kern, C-System, Assembler u.s.w.) stand uns dreimal woechentlich fuer vier Stunden als Crosssystem die schon erwaehnte pdp11/34 aehnliche Anlage mit, wenn alle vier Wechselplatten-Laufwerke zufaellig mal in Ordnung waren, 10 MByte externem Speicher und vier Termi- nals zur Verfuegung. Genug der Horrormeldungen, ich koennte noch viel hinzufue- gen. Am uebelsten waren die Bedingungen fuer lange Zeit wohl im LfA. Nun aber zum eigentlichen Thema: Wie Sie sich vorstellen koennen, waren die, sagen wir mal UNIX-Kenner, mit Transporten, Adaptionen, Compilerbau und aehnlichem beschaeftigt. Wo sollte aber die Anwender-Soft- ware entstehen, die vor allem die WEGA-Nutzer forderten? Das EAW ist auf dieser Strecke nicht untaetig gewesen, es blieb aber das Problem, dass unsere Kunden unbedingt Word- star, DBase und aehnliches wollten, weil sie in der Mehr- zahl aus der CPM-Welt kamen. Und gleichzeitig gab es immer wieder den Wunsch, ein Paket, wenn es denn schon unter UNIX sein musste, dann wenigstens auf all den vefuegbaren UNIX- Systemen gleichermassen einsetzen zu koennen. Was Datenbanken anbelangt, so gibt es hier bei uns inzwi- schen eine Reihe von Sytemen, alle an Vorbilder angelehnt, aber nur ein System, das obigem Kriterium wirklich genuegt: Es laeuft tatsachlich bei ungefaehr 200 Anwendern, und zwar auf tatsaechlich allen uns bekannten UNIX-Systemen und Rechnern in der DDR und, oh Schande, sogar unter MS/DOS - die Zahl der MS/DOS Anwender kenne ich aber nicht. Das System nennt sich ING_DB oder DABA16 oder INDES, abhaen- gig davon, von wem man es bezieht, ihm liegt aber ein, im ZKI von Herrn Wenzlaff gewarteter Qellenstand, zu Grunde. Herr Wenzlaff kam von der Staatsbibliothek unter den Linden ins ZKI, nachdem die dort mit der Entwicklung eines Datenbanksystems fuer Bibliothekszwecke beschaeftigte Arbeitsgruppe auseinandergelaufen war. Seine letzte Arbeit in der Stabi war die Wiederingangsetzung der Ingres-Version, von der ich oben schon kurz gesprochen hatte. Seine erste Aufgabe im ZKI war, dieses oder ein aehnliches System fuer den spassigen Rechner von oben, an dem inzwi- schen eine furchtbar laute Festplatte hing, bereit zu stel- len. Er hat aber seine Ziel von Anfang an sehr viel weiter abgesteckt und dann auch systematisch verfolgt. Der Anteil userer Gruppe an diesen Arbeiten beschraenkt sich auf gelegentliche Diskussionen und eine gewisse Mehrarbeit von unserer Seite, weil er, als Arbeitskraft, nach dem ersten Jahr stets fuer andere als Datenbankvorhaben eingeplant war. Nun werde ich im wesentlichen den Aufzeichnungen von Herrn Wenzlaff folgen: Mitte 1986 begann die Entwicklung von ING_DB als einhetli- chem Datenbanksystem fuer UNIX-Systeme auf unterschiedlichen Rechnerarchitekturen. Der Schwerpunkt der Arbeiten lag nicht auf dem Entwurf eines neuen Datenbanksystems sondern vielmehr auf der zu erreichenden Portabilitaet. Als Ausgangspunkt bot sich die Uebernahme der INGES-Konzepte an. Fuer die Datenbanksysteme INFORMIX, UNIFY oder ORACLE gab es in der DDR z.T. sogar Quellen, die aber leider nicht of- fen zugaenglich waren. Das Datenbanksystem INGRES wird heute von INGRES Inc., (ehemals RTI = Relational Technology Inc.) entwickelt und vertrieben, es beruht auf einem Forschungsprojekt der University of California Berkeley / USA, das 1973 von den Professoren Stonebreaker und Wong initiiert wurde. 1976 trat Professor Rowe dem Projekt bei. Das Konzept und die Implementierungen wurden stets sehr offen und genau publiziert. Das System besteht in seinem Kern aus einer Abfragesprache QUEL (Querry Language), die auch in Programmiersprachen eingebettet werden kann. (Embedded QUEL = EQUEL) und einer Reihe von Hilfsprogrammen fuer den System- bzw. Datenbank- administrator. Als Entwicklungsrechner wurde anfaenglich eine pdp11/40, spaeter eine pdp11/45 und schliesslich eine VAX11 verwendet. Die pdp11/40 hat fuer heutige Programmierer eine interessan- te Eigenschaft, sie unterstuetzt nur Programme deren Programmcode und -daten plus Stack nicht mehr als 64 KByte gross ist. Ein Datenbanksystem musste also, neben der 3-Schichtenarchi- tektur, funktional dekomponiert werden, um auf solchen Rechnern implementiert werden zu koennen. UNIX ist zwar ein multi-user und multi-task System, die Ver- staendigung zwischen einzelnen Prozessen ist jedoch bei den aelteren UNIX-Systemen schwach entwickelt. Die einzige bei V7 nutzbare Kommunikationsmoeglichkeit sind die pipes. Muss man sie nutzen, sind klar definierte Schnittstellen zwischen den Funktionen erforderlich. Das Datenbanksystem, genauer die Anfregesprache QUEL, be- steht aus mindestens zwei Prozessen, dem Terminal- und dem Datenbankprozess. Diese Zweiteilung ist notwendig, da der Terminalprozess im Verzeichnis des Nutzers und mit dessen Zugriffsberechti- gungen arbeitet, waehrend der Datenbankprozess im Verzeich- nis der Datenbank mit der Berechtigung des Datenbanksystems arbeitet. Der "Datenbankprozess" zerfaellt in die Funktionen: - Anfrageuebersetzung - Anfragemodifizierung - Anfrageoptimierung - Anfragebearbeitung (Anfrageinterpreter) - Dienstprogramme Jede Funktion kann in einen seperaten Prozess gelegt oder mit einem anderen kombiniert werden, so dass der Datenbank- prozess ein bis fuenf Prozesse und das Gesamtsystem zwischen zwei und sechs Prozessen benoetigt. Temporaer werden weitere Prozesse erzeugt, die aber hier nicht weiter behandelt werden sollen. Es ist verstaendlich, dass aus der Sicht des Betriebssystems die Abarbeitung einer Anfrage eine erhebliche Ressourcen- belastung darstellt und demzufolge auch eine gewisse Zeit dauert. Die eingebettete Version der Anfragesprache aendert an diesen Verhaeltnissen wenig, da nur der Terminalprozess durch das Datenbankprogramm ersetzt wird und alle Anfragen an den eben geschilderten Datenbankprozess weitergereicht werden. Soviel zu dem INGRES, wie es aus Berkeley ueberkommen ist. Nun zu den eigenen Aktivitaeten: 1) Das Datenbanksystem ist so entwickelt worden, das es in Ab- haengigkeit von der im Betriebssystem zulaessigen Programm- groesse generiert werden kann. 2) Alle Dienstprogramme, deren Leistungsumfang im Vergleich zum Orginal erheblich erweitert wurde, laufen in 64 KByte, bzw. sind Folgen von solchen Programmen. 3) Wie schon erwaehnt laeuft das nun als ING_DB bezeichnete Produkt auf allen in der DDR bekannten Rechnerarchitekturen unter allen moeglichen UNIX Versionen. Eine Aufzaehlung moechte ich mir hier ersparen, aber WEGA und PSU sind dabei. 4) Als erweiterte Funktionalitaet, die aber noch nicht wesent- lich ueber das vom UniversitaetsINGRES gebotene hinausgeht, wird geboten: - Reorganisation als eigenstaendige Funktion - Die Groesse einer Relation wird nur durch das Betriebs- system beschraenkt - Eine um den Faktor vier schnellere Sortierfunktion - Die Seitengroesse (ein Tupel muss in eine Seite passen) kann Datenbank-spezifisch festgelegt werden - Die max. Domaenenzahl wurde erweitert - Der Komplex Zugriffsschutz, Integritaeten, komplexe Sichten (alles unter dem Stichwort Anfragemodifizierung zusammengefasst) wurde voellig ueberarbeitet. Er ist nun in sich stimmig und, wenn auch noch nicht perfekt, so, dass die Anwender keine Klagen erheben. - Einige ueble Luecken bei paralleler Nutzung des Systems wurden beseitigt. 5) Ganz neu hinzugekommen sind: - Ein Reportsystem, das auch Datenbank-unabhaengig nutzbar ist. - Ein Transaktionsbegriff wurde intern durchgaengig ein- gebracht. Das fuehrte zu einem Transaktionsmanager, der jedoch (noch) nicht in die Anfragesprache hochgereicht wurde. D.h. dort gilt: eine Anfrage entspricht einer Transaktion. 6) Nun zur wesentlichen Erweiterung, um derentwillen der ganze Vortrag eigentlich gehalten wird: Eine Datenbanksprache, AMX genannt ist hinzugekommen. Sie zerfaellt in Datenbank-spezifische Teile und reinen C-Code, sie kennt den Transaktionsbegriff und gestattet rekursives Arbeiten, d.h. z.B. Stuecklistenprobleme sind mit ihr behan- delbar. Zu dieser Sprache gibt es einen Compiler, realisiert als C-Precompiler, der Programme dieser Sprache in C-Programme uebersetzt, die nach entsprechenden Compile- und Link- laeufen als ein Prozess abgearbeitet werden koennen. D.h. die Metadatenarbeit wird zur Compile-time erledigt, die DB-Anfragen werden nicht mehr interpretativ, sondern direkt in ein C-Programm transformiert, abgearbeitet. Im Prinzip fuehrt dieser Ansatz zu einem C-Programm, wie es ein C-ISAM Anwender fuer sein Problem schreiben wuerde. Die Abarbeitungszeiten sind vergleichbar, der Aufwand des AMX-Programmierers fuer die Datenbankseite des Problems duerften erheblich geringer sein. Die Abarbeitung von AMX-Programmen ist natuerlich an die Datenbankstrukturen gebunden, wie sie zur Uebersetzungszeit vorgelegen haben. Was fehlt bei ING_DB ? - Die bunte Oberflaeche (von Wedekind mal als Gruenzeug bezeichnet), aber ernsthaft: Maskengeneratoren, Querry by Example und eine SQL-Schnittstelle werden gewuenscht. - Eine Ausweitung auf wirklich verteilte Datenbanksysteme. Aber als Erlaeuterung der bisherigen Strategie: - Wir hatten harte Projekte, die meist auch mit Datenpro- blematik zu tun haben, aber eben nur unter anderem, im Blick und wollten den Programmierern die Muehen der Basiszugriffsmethoden ersparen. - Die desolate Hardwaresituation in der DDR hat bisher eine eine Entscheidung der Art, "von nun an nur noch fuer 32-Bit Architekturen mit virtuellem Speicher" von vornherein verboten. - Falls es genuegend Interessenten gaebe, wuerden wir die bisherigen Beschraenkungen fallen lassen und erheblich ausbauen, z.B. in Richtung einer X-Window Anbindung. Und das dann auch mit mehr Kraeften als nur Herrn Wenzlaff, dessen beachtliche Leistung ich hier auch noch einmal wuerdigen moechte, denn er hat nicht nur das erledigt, wovon ich bisher gesprochen habe, er hatte auch die Auslieferung, das ging bis zum Schnueren der Paeckchen mit den Disketten, und die Anwenderbetreuung am Halse. Ich danke Ihnen fuer Ihre Geduld und stehe fuer Ihre Fragen zur Verfuegung.