ULM - Um ein Desaster für das Landesturnfest in Ulm zu vermeiden, mußte innerhalb von drei Monaten ein effizientes Datenbankkonzept realisiert werden. Problemstellung sowie die Zeitbeschränkung erforderten eine parallel zur Programmierung laufende Systemanalyse. Große Testläufe waren nicht möglich. Axel Schreiner* beschreibt, wie er und seine Mannschaft mit Hilfe der unter Unix zur Verfügung stehenden Werkzeuge die Lösung strickten.
Vom 28. Juni '84 bis 1. Juli '84 fand in Ulm das 56. Landesturnfest des Schwäbischen Turnerbundes statt. In Anlehnung an das Deutsche Turnfest im Sommer 1983 in Frankfurt sollte die EDV von dem damals beauftragten Softwarehaus den Bedürfnissen eines mehr regionalen Turnfestes (den Gepflogenheiten der Turner gemäß, jedoch mit internationaler Beteiligung) angepaßt werden. EDV war dringend vonnöten - sollten doch an 700 Vereine für etwa 20 000 Teilnehmer Festkarten, Netzkarten, Wettkampfkarten und (nicht zu vergessen!) Rechnungen erstellt und verschickt werden. Während der zwei Wettkampftage sollten 10 000 Wettkampfteilnehmer (zum größten Teil Mehrkämpfer mit meistens vier Einzeldisziplinen) erfaßt werden. Korrekte Ranglisten, jeweils dem momentanen Stand entsprechend, waren für Presse und die abschließenden Siegerehrungen in schneller Reihenfolge notwendig. Zum Anschluß (Dabeisein ist alles!) sollten Tausende von Siegerurkunden gedruckt, und deren Verteilung organisiert werden.
Per Knopfdruck machten sich Daten selbständig
Ein angeblich geeignetes Programmpaket (mit einer Datenbank unter USCD Pascal auf einem Netz von Mikros) stand theoretisch auch zur Verfügung. Es war zu einem stolzen Preis für das Deutsche Turnfest in Frankfurt - laut Kaufvertrag anpaßfähig an kleinere Festchen - entwickelt worden.
Am 1. April lag zum Meldeschluß in Ulm ein Berg von Meldungen, aber kein funktionierendes Erfassungsprogramm war greifbar, um die Teilnehmer vor Beginn der Wettkämpfe wenigstens zu erfassen. Zur Planung des Turnfestes (Organisation der Ansittszeiten, Anzahl der benötigten Geräte etc.) wären genaue Zahlen notwendig gewesen. Beim Probelauf Mitte März mit dem Frankfurter Programm zeigte sich, dank der wenig präzisen eben für Frankfurt entwickelten Wettkampfnummern, daß die Ausschreibung für 80 Prozent der Sportler zu kompliziert war. Beliebige Fehler auf den eingegangenen Meldebögen, die Gepflogenheiten der Turner und die "anpassungsfähig" hart im Pascal Programm stehenden Nummern (die Programm-Quelle bekamen wir nicht) machten eine zügige Erfassung unmöglich. Zu allem Überfluß konnten die Erfasser bei naivem Knopfdruck in einer Vielzahl von Masken mühelos verlorengehen.
Geschwindigkeit ist keine Hexerei
Nach dem Motto vom Spatz in der Hand - für Ulm sehr passend - wurde die Firma am 1. April von ihren Pflichten entbunden, und wir machten uns zu dritt mit Unix ans Werk. Mangels Kenntnissen und sofortiger Verfügbarkeit schieden der Einsatz einer Datenbank und andere Experimente von vornherein aus.
Grundstock war ein in 16 Stunden in "C" erstelltes Erfassungsprogramm. Es enthielt Zugriffssynchronisation, Schirmmasken, Bedienerführung und Prüfung der Ein-/Ausgabe. Dieses Erfassungsprogramm beseitigte zunächst einmal die Flut von Meldungen und schaffte eine Basis für statistische Zwecke. Auszählen war eines der Hauptmerkmale für die Organisation. Zu Beginn war als "Leihrechner" nur eine PDP-11/ 23 mit 80 MB Winchester vorhanden. Mit zuerst zwei, später bis zu fünf Erfassungspersonen wurde der Berg der Meldungen zügig abgearbeitet. Ein kurzzeitiger Versuch, zehn Erfassungsplätze zu betreiben, zeigte die Grenzen der zu diesem Zeitpunkt verfügbaren Hardware. Für einen komfortablen Teilnehmerbetrieb mit gleichzeitiger Entwicklung ist das System PDP-11/23 zu klein.
Wir zogen (auf der Hannover-Messe) aus, einen Sponsor zu finden, der uns ein leistungsfähigeres System zur Verfügung stellen sollte. Perkin-Elmer überließ uns einige Wochen später ein System 3210 mit 2 MB und 80 + 16 MB Platte, von Mannesmann-Tally bekamen wir zwei Drucker, und von der Universität Ulm requirierten wir mehr und mehr Bildschirme. An den Wettkampftagen selbst erfaßten wir Daten an etwa 14 Arbeitsplätzen (im Schnitt doppelt so schnell wie über das Mikro-Netz in Frankfurt), sicherten kontinuierlich auf Wechselplatte und Band und hatten noch Kapazität frei. Ein zweiter Unix-Rechner - der Ulmer Schulrechner - stand im Falle einer Katastrophe bereit. Daten und Programme wurden übrigens von der PDP- 11 zur 3210 mangels Magnetband per Terminalleitung (in 36 Stunden!) übertragen: Die Programme funktionierten auch auf dem 32-Bit-System auf Anhieb wieder,
Logische Bedienerführung mit PANIC-Taste
Wie kommt man ohne Mitarbeiterschulung aus? Die erste wesentliche Entscheidung war, die Schirmmasken so ähnlich wie möglich zu den Meldebögen zu machen und die Erfassung möglichst logisch an den Masken vorbeizuführen, um diesen Vorgang zu beschleunigen. Funktionstasten taten ein übriges. Im Gegensatz zum Vorgänger wurde das Programm vom Erfassungspersonal sehr leicht akzeptiert.
Am "beliebtesten" war die "Panic"-Taste, die es dem Erfasser ermöglichte, nach Eingabe beliebiger Fehler, ohne Hinterlassung von Spuren in der Datenbank, wieder in den Grundzustand zurückzukehren, um den gerade in Arbeit befindlichen Teilnehmermeldebogen oder Vereinsmeldebogen nochmals (oder auch nicht) zu erfassen.
Die zweite Entscheidung bestand darin, im C-Programm die Masken nach (im wesentlichen) geometrischen Gesichtspunkten durch Strukturen (statisch) abzubilden, und dies nicht von den logischen Komponenten (Teilnehmername, Alter etc.) abhängig zu machen. Inzwischen (nach vier Stunden mit yacc und lex, den Compiler-Tools) besitzen wir auch einen entsprechenden Prozessor zur Definition der Masken.
Transportable Software für viele Systeme
Als drittes beschlossen wir, die Daten für einen Teilnehmer in der Reihenfolge der Erfassung auf einen Bildschirm in einer Datei (pro Teilnehmer) abzulegen. Felder sind dort alphanumerisch, variabel lang, durch TAB getrennt und logisch in Zeilen zusammengefaßt. Eine solche Datei kann mit völlig normalen Unix-Werkzeugen (Editor, awk, sort, pr) betrachtet werden, und Zugriffssynchronisation für Dateien ist in jedem Unix-System problemlos zu erreichen. (Die Erfassungssoftware lief inzwischen auf Perkin-Elmer-, PDP-11-, Altos- und Unix- beziehungsweise Xenix-Systemen unverändert.)
Leid mit Korrekturen - Korrekturen mit Leid
Sich zum Teil widersprechende Ausschreibungsbedingungen, zum Teil fehlende der Ausschreibung, doppelt verwendete Wettkampfnummern und ein wahrhafter Schatz turnerischer Gepflogenheiten führten zu einem monumentalen Programm für die Prüfung der Teilnehmermeldungen.
Aus Effizienzgründen (und weil zu Beginn die Bedingungen nicht faßbar waren) prüfte das Erfassungsprogramm nur auf Plausibilität. Eine harte Prüfung fand später im Stapelbetrieb statt (sind für eine Mannschaft auch genügend Einzelmeldungen vorhanden?). Eine Diplomandin war voll damit beschäftigt, die Prüfbedingungen überhaupt erst zu präzisieren! Ein promovierter Mathematiker bemühte sich in den Osterfeiertagen darum, die Prüfbedingungen in ein Programm umzusetzen. Das Prüfprogramm war von der internen Darstellung der Datenbank unabhängig. Es überlebte deshalb die verschiedenen Phasen der Neuorganisation der erfaßten Daten. Von anfänglich etwa 20 Prozent Meldefehlern arbeiteten wir uns in vier Wochen auf null Fehler - durch Aufweichen der Meldebedingungen und durch wirkliche Korrektur der Daten.
Erste Abfragen über die erfaßten Daten konnten mit awk vonstatten gehen. wc erfüllte zum Auszählen wertvolle Dienste. Häufige Abfragen erfordern aber das Erstellen von invertierten Listen. Typische Sichten auf die Daten lassen sich dann zufriedenstellend schnell realisieren. Somit entstand ein Extraktor-Programm, analog zu awk, aber besser zur Erzeugung neuer Dateien geeignet, und wesentlich schneller. Es realisierte in Unix-typischer Art über viele Argumente, analog zu find - dem Dateisuchkommando -, die Datenbank-Abfrage Sprache. Ideen und Auswahl der notwendigen und typischen Abfragesprachelemente wurden SQL bzw. SEQUEL entnommen. SQL setzt sich als Abfragesprachentyp für Datenbanken immer mehr durch. Auf verbale Auslegung der Abfragesprache wurde in UNIX-Art verzichtet.
Der Extraktor diente zum Füttern des Prüfprogramms ebenso wie später zur Anlieferung der Daten für die Rechnungsstellung. Mit Hilfe des Extraktors konnten invertierte Listen ("Wer macht Orientierungslauf?" "Friesenkampf?" "Wer will am Freitag Frühstück im Quartier x?") und alle möglichen Reports generiert werden. Wir erweiterten auch mehrfach alle Teilnehmerdateien um weitere Felder. Eine Symbiose aus Shell-Programmierung und entsprechenden speziellen Programmen war in dieser Phase ein unüberschätzbares Hilfsmittel.
Das Hierarchiebewußtsein der Sportler unterstützte den Aufbau eines hierarchischen Datenbankkonzepts. Ein Teilnehmer ist typischerweise Mitglied in einem Verein (im Zweifelsfalle im Verein "Ehrengäste"). Vereine sind in Gaue zusammengefaßt. Das Format der Teilnehmerdateien und ihre Gruppierung in Directories für Vereine und in übergeordnete Directories für Gaue (der Baum wird schlanker und der Zugriff schneller!) erwies sich als sehr flexibel. Is, das Directory Dienstprogramm - oder auch das Suchprogramm grep - bildeten die primären spontanen Query-Werkzeuge. Eine Pipeline führte vom Extraktor etwa zum Rechnungsprogramm (klein, aber mit liebenswerten Eigenarten, etwa "kein Frühstück ohne Quartier oder auf dem Zeltplatz", "Frühstück aber kein Quartier für Musiker, aber nicht für Leistungsmusiker"), und von dort zum Formatierfilter der Bankeinzüge. Deren rohe Information wandelten wir per awk in eine C-Tabelle, die dann beim zweiten Lauf des überarbeiteten Rechnungsprogramms zur Korrektur der ursprünglichen Lastschriften diente - es ist bemerkenswert, wie viele Turner am Wettkampftag mit ärztlichem Attest statt Medizinball agieren (müssen).
Umkopierprogramme in Minutenschnelle
Das sich erweiternde Anwendungsprofil bedingte zweimal eine Umorganisation der Daten. Es kamen neue Felder hinzu, und es wurden Felder umsortiert. Die notwendigen Umkopierprogramme waren in Minutenschnelle erstellt. Nur in der Definitionsdatei waren Details über den Aufbau der Daten im System enthalten. Der PATH-Suchmechanismus der Shell vereinfachte das "Umhängen" von der alten zur neuen Fassung. Weder Erfassungspersonal noch die Mitarbeiter des Organisationskomitees (geschweige denn die über Pipelines angeschlossenen Programme) bemerkten die Neuorganisation.
Überhaupt - Änderungen: Es gibt nichts, was nicht irgendein Teilnehmer geändert haben wollte. Der Wettkampfresultate speicherten wir zwar in den Teilnehmerdateien, aber auch noch sequentiell pro Disziplin und Erfassungsplatz zwecks schnellerer Produktion von Siegerlisten und Urkunden. Korrekturen wurden in den Teilnehmerdateien ersetzt und ebenfalls sequentiell per Disziplin registriert. Ein einfaches spezielles Merge-Programm und viele Pipelines zu Standard-Tools produzierten Ranglisten, davon Siegerlisten, Urkunden etc. Erfassungszeitstempel in den Dateien halfen, Wettkampfarten bei Reklamationen leicht zu lokalisieren. Gegen den Kampfrichter, der beim 100-m-Lauf die Zeit nur auf dem Teilnehmerabschnitt, aber nicht auf der Wettkampfkarte für die EDV aufschrieb, war natürlich jede Korrekturvorkehrung machtlos . . .
Unix-Schnellschuß läuft in neuen Diensten
Insgesamt haben wir weniger als neun Mannmonate in den drei Monaten zwischen Meldeschluß und Turnfest eingesetzt und alle Termine gehalten. Trotz Streik erschien die Festzeitung mit allen verfügbaren Resultaten am Abend des zweiten Wettkampftages. Die Erfassung der Wettkampfdaten selbst war nachts vier Stunden früher als erwartet beendet.
Am Sonntagabend nach Wettkampfschluß wurden (gauweise!) Ranglisten gedruckt. Anschließend und zum Teil parallel wurden Urkunden, geänderte Rechnungen, Lastschriften etc. gedruckt und verschickt. Auch für die "papierverarbeitende Industrie" erwies sich das eingesetzte System sehr leistungsfähig und variabel einsetzbar.
In der Hand der Autoren zeigten sich alle Programme sehr anpassungsfähig an die fast täglich neuen Vorstellungen der Turner. Die Software für Schirmmasken ist problemunabhängig. Sie wird inzwischen schon für andere Aufgaben eingesetzt und für weitere vorgesehen.
aus: unix/mail 3/84
*Professor Dr. Axel Schreiner, Brigitte Weißhaar und Dr. Ernst Janich, Bereich Informatik, Uni Ulm