diff --git a/WEGA/contrib/ingres/dbs/tmp/ing_Vortrag b/WEGA/contrib/ingres/dbs/tmp/ing_Vortrag new file mode 100644 index 0000000..ac65ff6 --- /dev/null +++ b/WEGA/contrib/ingres/dbs/tmp/ing_Vortrag @@ -0,0 +1,311 @@ +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.