"Microsoft und IBM haben ueber unseren Koepfen Pingpong gespielt. Jeder Hersteller schob dem anderen die Schuld an unseren Problemen zu", macht Franz Eckl, Leiter der Systementwicklung beim BR, seinem Aerger Luft. "Fuer Microsoft waren wir schlichtweg zu unbedeutend. Dort hat man sich um uns gar nicht gekuemmert. Erst auf mehrmaliges Nachfragen erfuhren wir: Der Fehler liegt bei der IBM." Die IBM ihrerseits reagierte schneller, und die Hotline war an sich sehr gut, erzaehlt Eckl. Gebracht habe das freilich auch nicht viel. Man habe sich bei IBM an die jeweiligen Labors gewandt, aber auch dort die unbefriedigende Auskunft erhalten: "Der Fehler liegt bei Microsoft." Den verlorengegangenen Projektaufwand schaetzt Eckl auf etwa ein Mannjahr.
Bei 350 Stellenausschreibungen und 25000 Bewerbungen im Jahr sah sich die Personalabteilung nicht mehr in der Lage, diesen Datenwust manuell zu verwalten. Um sicherer und flexibler auf die Informationen zugreifen zu koennen, initiierte die Personalverwaltung das Projekt Bewerbungsverwaltung. Etwa 20 Mitarbeiter sollten mit der neuen Applikation arbeiten.
Ende 1994 begannen die DV-Mitarbeiter mit der Analyse und der Spezifikation. "Wir wollten eine moderne Anwendung auf Client- Server-Basis. 3270-Oberflaechen sind nicht mehr zeitgemaess", erlaeutert Eckl. Dennoch sollte der Zugriff auf die Grossrechnerdatenbank DB2 erfolgen, da dort die Betriebsdaten liegen und das System als stabil und sicher gilt. Verbindungen waren vorgesehen zur Personendatenverwaltung, Finanzbuchhaltung, Kostenrechnung und Stellenplanung. Das Unternehmen entschied sich fuer Access als Entwicklungs-Tool und die integrierte Datenbank- Engine "Jet". "Aus meiner Sicht verfuegt Access ueber eine der schoensten Programmieroberflaechen", begruendet Eckl die Wahl. Die Verbindung zu DB2 sollte ueber einen OS/2-Server mit den Gateways DB2/2 und DDCS/2 hergestellt werden (vgl. die Abbildung auf Seite 16). Zwischen dem Front-end und dem Datenbank-Gateway vermittelte die Schnittstelle Open Database Connectivity (ODBC), die fuer solche Zwecke als Standard gilt.
Weil das Team meinte, zu diesem Zeitpunkt noch nicht genuegend Erfahrung in der Windows- und GUI-Programmierung zu haben, ging der Programmierauftrag ausser Haus an die Firma Sofcom in Muehltal. Diese entwickelte die Applikationslogik und die grafischen Oberflaechen.
Derweil wurde beim BR das IBM-Betriebssystem OS/2 installiert und der "Communication Manager" (CM/2) in Betrieb genommen. Danach erfolgte der Aufbau lokaler Funktionen, des Gateways DB2/2 und die Verbindung zum Host. Im naechsten Schritt erhielten die Windows- Clients ueber Novells Netware und ODBC Anschluss ans Netz. Das BR- Team fuehrte erste Funktions- und Performance-Tests mit Hilfe des Excel-Zusatzes "MS-Query" aus, indem Lese- und Schreibzugriffe auf DB-2-Tabellen ausprobiert wurden. Diese Projektphase nahm etwa drei Wochen in Anspruch.
Design- und Implementierung dauerten zusammen ungefaehr neun Monate. Dabei wurden die auf dem Host vorhandenen Tabellen in Access importiert und weitere SQL-Ressourcen lokal definiert. Es zeigte sich unter anderem, dass sich ein 486er PC mit weniger als 16 MB RAM nicht fuer den produktiven Einsatz eignen wuerde. Die vorhandenen PCs wurden ersetzt oder aufgeruestet. Dennoch stuft Eckl die Probleme bis dahin als fuer ein DV-Projekt ueblich ein. Man erwartete auch keine tiefergehenden Schwierigkeiten, da ausschliesslich gebraeuchliche Produkte eingesetzt wurden.
Die Funktions- und Performance-Tests bis zum Abschluss dieser Phase blieben lokal beschraenkt oder sollten lediglich sicherstellen, dass die Verbindung zwischen Windows und DB2 funktioniert, also Daten bei akzeptabler Geschwindigkeit austauschbar sind. Nicht geprueft hat das DV-Team beim Bayerischen Rundfunk die Kompatibilitaet von PC und Host, von Access- und DB2-Formaten.
"Unser Trugschluss bestand darin, den Versprechungen der Hersteller zu glauben, mit ODBC gebe es solche Probleme nicht, wie sie bei uns waehrend der Integration auftraten", bilanziert Eckl.
So liefert die DB2-Funktion "Current Timestamp" einen Schluessel mit dem Format Jahr, Monat, Tag, Stunde, Minute, Sekunde, Mikrosekunde. Access kennt dieses Format nicht und schneidet bei der Uebernahme der DB2-Daten den Mikrosekundenanteil ab. Beim Zurueckschreiben ist der Wert fuer die Mikrosekunden deshalb immer gleich Null. Damit geht aber die Eindeutigkeit des Schluessels "Timestamp" verloren. Das ist laut Eckl bei einer Datenbank, die seit neun Jahren im Einsatz ist, die gesamte Betriebsorganisation abbildet und auf die Hunderte von Benutzern zugreifen, kein triviales Problem.
Ausserdem verfuegt Access ueber keinen Datentyp fuer Datumseingaben. Ein Datum entsteht, indem nur der relevante Anteil des Zeitstempels uebernommen wird. Das groessere Problem liegt bei Access aber darin, dass keine Datumsangaben vor dem Jahr 1900 angenommen werden. Der BR benutzt jedoch den 1. Januar 0001 etwa bei unbekannten Todesdaten. Access macht daraus den 1. Januar 1901, womit der Eintrag verfaelscht waere.
Unter den grundlegenden Regeln Edgar Codds fuer relationale Datenbanken findet sich der Datentyp "Character", ein Format mit fester Laenge. Daneben existiert zum Beispiel in DB2 ein Charaktertyp mit variabler Laenge: "Varchar". Waehrend DB2 beide Formate akzeptiert, kennt Access nur den Typ Varchar. Bei der Datenuebernahme in Access wird deshalb aus dem DB2-Format Character der Typ Varchar. Wenn anschliessend Tabellen abgeglichen oder gekoppelt werden, muessten unterschiedliche Datentypen herhalten, was nicht funktioniert.
Unliebsame Ueberraschungen erlebte die BR-Crew auch mit dem in Access verwendeten SQL-Dialekt. Sind bei einer Datenbankabfrage zwei oder mehrere Tabellen betroffen, loest Access die SQL- Statements in entsprechend viele einzelne Befehle auf.
So zieht Access bei einem kombinierten "Select"- "Where"- "Order"- Befehl mit zwei Tabellen die erste Tabelle heran, laesst sich alle Datensaetze liefern, speichert die Daten auf dem PC, und gibt den zweiten Request an das ODBC, laedt die zweite Tabelle und verknuepft die gewonnenen Daten auf dem PC. "Das ist fuer jeden PC toedlich, denn es koennen Tabellen beteiligt sein, die bis zu einer Million Zeilen, sprich Datensaetze, haben", kritisiert Systemspezialist Eckl.
Zu diesem Problem bot Microsoft das sogenannte "Pass-Thru-SQL" an. Eckl lehnte entruestet ab: "Dann habe ich denselben Aerger wie auf dem Host, ich muss die SQL-Befehle per Hand eintippen." Der Vorteil grafisch unterstuetzter Entwicklung, die Access bieten soll, waere hinfaellig.
Access verlangt bei Datenaenderungen ueber Sichten (Views), dass fuer jede View lokal auf dem PC ein eindeutiger Index angelegt wird. Fuer fuenf verschiedene Benutzer muss fuenfmal ein Index angelegt werden. Formal ergibt sich damit eine Redundanz, inhaltlich koennen sich die betroffenen Tabellen jedoch unterscheiden. Es entsteht ein Mehraufwand fuer die Pflege der Indices und Inkonsistenz der Daten.
Dass Access kein statisches SQL kennt, ist fuer Eckl ein weiterer Mangel. Zwar sei das dynamische SQL wesentlich flexibler, da die SQL-Statements hier erst bei der Ausfuehrung zur Interpretation uebergeben werden. Doch kostet diese Art der Verarbeitung gerade wegen ihrer Flexibilitaet Zeit, denn die optimalen Zugriffspfade muessen erst gefunden werden. Beim statischen SQL entsteht durch einen Precompiler ein Database-Request-Modul, das die aus dem Programm herausgefilterten und umgewandelten SQL-Befehle enthaelt. Daraus entsteht beim Kompilieren Objektcode, ein ausfuehrbares Programm. Durch einen Bindevorgang speichert die Datenbank den Inhalt getrennt von dem Programm, so dass sich bei der Programmausfuehrung schnell darauf zugreifen laesst.
Bei der Vergabe von Zugriffsrechten zeigt sich ein weiterer Vorteil des statischen SQL. Berechtigungen lassen sich an den SQL- Block, den Plan, vergeben, waehrend beim dynamischen SQL die Rechte pro Tabelle zugeteilt werden muessen. Das waere auch fuer die Bewerberverwaltung des BR eine aufwendige Angelegenheit gewesen, da sich etwa 60 Tabellen hinter der Applikation verbergen.
Noch zahlreiche Kleinigkeiten kann Eckl aufzaehlen, die ihm das Client-Server-Pilotprojekt verleidet haben. Im November vergangenen Jahres wurde es gestoppt. "Wir mussten einsehen, dass wir nicht mehr weiterkamen. Das war bitter", sagt der Systemchef.
Aufgegeben hat die BR-Mannschaft dennoch nicht. Ende vergangenen Monats wurde die Bewerbungsverwaltung fertiggestellt - mit "Powerbuilder" von Powersoft und ohne ODBC.
Die Host- und PC-Umgebung
Der Bayerische Rundfunk setzt einen IBM-Rechner des Typs 9121-521 mit 512 MB Speicher und einer Leistung von 44 Mips ein, der mittels Logical Partitioning (LPAR) die Betriebssysteme MVS und VM parallel ausfuehrt. Zu den wichtigen Peripheriegeraeten zaehlen RAMAC-Platten mit 110 GB, die Datenvermittlungs-Steuereinheit IBM 3745-210 sowie mehrere Terminalsteuereinheiten IBM 3174, die zum Teil mit einem Token-Ring-Anschluss versehen sind.
Als Endgeraete dienen 3270-Terminals von IBM und HOB, PCs mit 3270- Emulation und Drucker. Betrieben wird das Host-Netz unter dem IBM- Protokoll SNA auf Koax-, Token-Ring- und SDLC-Basis.
Die Anwendungsprogramme unter VM laufen als CMS-Anwendungen; in der MVS-Umgebung setzt der BR auf eine DB2-Datenbank und auf den Transaktionsmonitor CICS/ ESA. Programmiert wird vorzugsweise in Cobol, CSP und PL1 sowie in Zukunft auch in C++.
Im PC- und Netzbereich kommen Compaq-Geraete sowohl als Server als auch als Arbeitsplatzrechner zum Einsatz. Ein Desktop-System beruht auf 486er Prozessoren und 16 MB RAM. Die BR-Anwender setzen DOS, Windows, Excel, Word und HOB-Link 3270 ein.
Die Verbindung der Netzelemente basiert auf dem Novell- Betriebssystem Netware 3.12, wobei sowohl auf Token-Ring-Technik von IBM als auch auf Ethernet-Topologien gesetzt wird. Dabei sind ausschliesslich Olicom-Karten mit 16 Mbit/s im Einsatz.