Dr. Michael Peltzer, Chef Consultant der IBM Unternehmensberatung GmbH, Hamburg
In den USA kursieren furchterregende Szenarien. Aufgeregte Mahner warnen vor dem jüngsten Tag der Automated society: Am 1. Januar 2000 könnte die Welt untergehen. Gewissermaßen.
Der Anruf kommt am 2. Januar, Sonntagmorgen. Aufgeschreckt vom Frühstückstisch, nimmt Peter X. Hacker, DV-Leiter der Secumed-Versicherung, die Schreckensmeldung entgegen: Ein Putzprogramm hat am Vortag sämtliche Dateien auf den Systemplatten gelöscht, darunter auch die Produktionsdatenbasis. Es sollte Dateien entfernen, die seit über einem Jahr nicht mehr benutzt worden waren. Aus irgendeinem Grund hatte es alle Dateien für zu alt befunden. Im Lauf der nächsten Tage stellte sich heraus, daß der Secumed-Unfall kein Einzelfall war. Rund um den Globus hatten altgediente Programme angefangen verrückt zu spielen.
Die Ursache war bald gefunden: In allen Fällen war die Jahreszahl im Datum nur als zweistellige Variable codiert oder gespeichert worden und die Jahrhundertangabe entweder ignoriert oder fest mit "19" eingetragen. Ganz Clevere hatten die Jahreszahlfelder in Dateien auch noch mehrfach belegt und Werte wie "00" oder "99" zur Kennzeichnung von Spezialfällen verwendet, weil solche Werte ja als Jahreszahlen "praktisch nie vorkommen".
Probleme mit dem Jahr 2000 hatte es schon in den Jahren davor immer öfter gegeben: Viele Programme wußten nicht, daß 2000 ein Schaltjahr ist, weil eine Regel besagt, daß Schaltjahre nicht durch 100 teilbar sind. Diese Regel hat eine Fortsetzung: "...außer, sie sind durch 400 teilbar", aber die hat natürlich keiner codiert. Wann kommt das schon mal vor? Wenn man sämtliche Exotenfälle abfragen wollte, wäre die Performance restlos beim Teufel.
Die Konsequenzen sind, verglichen mit der Ursache, ganz enorm: Weil "00" kleines ist als "99", liefern sämtliche Vergleichsoperationen zwischen Datumsfeldern falsche Ergebnisse. Außerdem funktionieren Kalkulationen auf Schaltjahre, Datumskonversionen und jede Menge anderer Berechnungen nicht mehr. Ob die Pflege der Historien bei einem Versicherer ob die Rechnungs- oder Mahnungsschreibung eines Händlers es gibt kaum eine kommerzielle Applikation, in der nicht wesentliche Verarbeitungsschritte von Datumsoperationen abhängig wären.
Das Problem ist nicht auf die kommerzielle DV beschränkt: jede Steuerung, die Termine realisiert und folglich Datumskalkulationen vornimmt, kann betroffen sein - von den Jobabläufen im RZ bis zur automatischen Gebäudesicherung. Apropos RZ-Betrieb: Können wir eigentlich sicher sein, daß nicht auch die Softwärefundamente der Informationsverarbeitung - Betriebssysteme, Datenbanksysteme, Transaktionsmonitore - mit heißer Nadel gestrickt wurden? Man wird ja mal fragen dürfen.
Was ist zu tun? Zuerst müssen die Produkte der eigenen Anwendungsentwicklung untersucht werden, die möglicherweise noch das Jahr 2000 erleben. Dann kann eine Renovierungsreihenfolge festgelegt werden - Zeit genug ist ja noch. Zu lange sollte man allerdings nicht warten, denn es kann sein, daß enorme Mengen von Code und riesige Datenbestände inspiziert und modifiziert werden müssen. Und vergessen Sie Ihre Softwarelieferanten nicht! Seien Sie stur, denn wahrscheinlich werden die Ihnen sagen, sie hätten Wichtigeres zu tun (als jetzt schon aufwendige Vorsorge zu betreiben für eine Zeit, in der es ihre Firma vielleicht gar nicht mehr gibt).
Das alles ist Business as usual: Es sind Reparaturarbeiten vorzunehmen und gegebenenfalls bei den Geschäftspartnern einzufordern. Das ist ärgerlich, aber keine Katastrophe. Trotzdem bleibt ein ungutes Gefühl zurück. Denn mit ziemlicher Sicherheit ist der "Reinfall 2000" kein Einzelfall. Es ist äußerst beunruhigend zu sehen, wie höllisch man in der ultramodernen DV-Welt noch immer aufpassen muß, und wieviel Arbeit und Kosten ein simples Datum verursachen kann.
Wie konnte es dazu kommen? Die Antwort ist einfach: Es ist am falschen Platz gespart worden. Zwei Stellen belegen weniger Speicher, und die Berechnungen werden dadurch einfacher und schneller. Sicher, es gab Zeiten, in denen Speicher und Prozessorleistung tatsächlich so knapp waren, daß man sich kein ganzes Datum leisten konnte. Doch die meisten der damals erstellten Routinen haben vermutlich längst ausgedient.
Woher aber kommen dann die vielen Programme, die bis zur Jahrtausendwende angepaßt werden müssen? Diese schöne Situation verdanken wir vermutlich dem Zusammenwirken zweier Umstände: zum einen der Gedankenlosigkeit der Programmierer, die einfach sparsam weitercodierten, auch als der technische Grund dafür längst entfallen war, zum anderen der Gedankenlosigkeit eines Managements, das keine Zeit, genauer: kein Interesse und wahrscheinlich auch keine Kompetenz hat, sich groß um die Anwendungsentwicklung zu kümmern.
Solange es nicht kracht, halten die Verantwortlichen ihre Produktionsweise für prima und achten lediglich darauf, daß die Termine eingehalten werden und keine jobbedrohende Standardsoftware ins Haus kommt. Qualitätskontrolle gilt ihren als Ressourcenverschwendung. Sie betrachten die eigene Produktion von außen - aus der Sicht, aus der das Management sie selbst beurteilt. Damit erscheinen selbst vernünftige Aufwendungen für die Verbesserung des Entwicklungsprozesses und seiner Produkte so lange als unnütz, wie ihr Nutzen für die Geschäftsführung und die Benutzer nicht unmittelbar einsichtig ist. Entscheidend ist nur, daß zum geplanten Termin der Bildschirm flimmert und ein Teil der geförderten Funktionalität realisiert zu sein scheint. Folgekosten gibt es noch keine, und aus deinen Wartungsbedarf ist ein imponierender Auftragsbestand geworden.
Trotzdem sollte man sich mit Vorwürfen zurückhalten. Und zwar nicht nur, weil sogar die Hersteller von Transaktionsmonitoren hin und wieder in einer Weise codiert haben, daß eine Geheimhaltung der Source schon aus Imagegründen nötig ist. Das wirkliche Problem sind Maßstäbe, die eine langfristig sparsame Entwicklung der Softwareproduktion behindern indem sie die kurzfristig billigeren Lösungen bevorzugen.
Denn Sparen an der falschen Stelle kann ziemlich teuer kommen. Siehe, oben.
PS: Vielleicht hat der "Reinfall 2000" ja auch sein Gutes. Immerhin ist es denkbar, daß jetzt intensiver über eine Ablösung von Altsystemen nachgedacht wird, und die böte in der Tat viele Möglichkeiten, es besser zu machen. Nicht nur, was die Wartungsfreundlichkeit angeht: Mit den Software-Altlasten entfiele auch ein Hauptargument gegen den Einsatz neuer Techniken wie verteilter Systeme oder Objektorientierung, nämlich der gern ins Feld geführte Investitionsschutz.