Alice im Wunderland, die Titelheldin von Lewis Carrolls klassischem Kinderbuch, wird von dem verrückten Hutmacher gefragt: "Zeigt deine Uhr das Jahr an?" worauf sie antwortet: "Natürlich nicht, aber das kommt daher, daß es so lange das gleiche Jahr bleibt."

Aus demselben Grund schreiben die meisten Leute – mich eingeschlossen – statt der vier Ziffern der Jahreszahl nur die letzten zwei: Es bleibt ja so lange das gleiche Jahrhundert. Und die frühen Computer-Programmierer hatten noch weitere gute Gründe, diese Gewohnheit zu übernehmen. Speicherplatz war noch vor wenigen Jahrzehnten ein kostbares Gut, und bei einer Lochkarte mit bescheidenen 80 Spalten Breite machen zwei Zeichen mehr oder weniger einen erheblichen Unterschied. Außerdem ersparte man sich das Tippen der Ziffern 19 bei jeder Jahresangabe, es gab keine Norm, welche die Langschreibweise vorgeschrieben hätte, und das Jahr 2000 war noch lange hin: Bis dahin, glaubten die meisten von uns, würde unsere Software längst durch neuere ersetzt sein. Welch ein Irrtum! Aus purer Trägheit behielt man die Kurzschreibweise bei, obgleich Knappheit an Speicherplatz und der Aufwand für die Dateneingabe längst keine Rolle mehr spielen.

Wozu hat das geführt? Weit verstreut in den Speichern der Computer stecken heute Jahreszahlen von beunruhigender Zweideutigkeit. Wie soll eine Maschine auch wissen, ob wir mit 00 das Jahr 1900 oder 2000 meinen? Verwechslungen dieser Art haben bereits zu Problemen geführt. Bei dem Flugzeughersteller Boeing traten 1993 Fehler in einem Progamm auf, das Bestellungen bis zu sieben Jahre im voraus plant. Ein System des Kosmetikkonzerns Amway wies Chemikalien zurück, weil es deren Haltbarkeitsdatum 00 als 1900 statt 2000 interpretierte, und computerisierte Ladenkassen versagten, wenn ihnen Kreditkarten mit Gültigkeit bis 2000 unterkamen. Nach einer Industrieumfrage vom vergangenen Jahr haben mehr als 40 Prozent der befragten Unternehmen den "Jahr-2000-Fehler" in dieser oder jener Form bereits zu spüren bekommen. In aller Munde geraten ist das Problem unter dem Kürzel "Y2K Bug": Y wie year, 2K wie 2 Kilo oder 2000 und bug (eigentlich ein lästiges Insekt unbestimmter Art) wie Software-Defekt.

Was könnte noch alles geschehen? Nehmen wir an, ein Kunde zahlt im Jahre 1999 einen Betrag auf ein Sparkonto ein und hebt ihn genau ein Jahr später wieder ab. Das Kontoführungsprogramm der Bank berechnet die Laufzeit für die angefallenen Zinsen, indem es das Einzahlungsjahr vom Abhebejahr subtrahiert (Zinsberechnung für angebrochene Jahre außer acht gelassen). In der zweistelligen Darstellungsweise wäre das 00 minus 99. Also wird der Computer glauben, das Geld sei -99 Jahre auf dem Konto gewesen, und das Konto mit 99 mal dem geltenden Sparzinssatz belasten, statt Zinsen für ein Jahr gutzuschreiben.



Das Wesen des Jahrtausendfehlers



Fehler dieser Art würden sofort auffallen. Heimtückischer ist der folgende: Versicherungen tilgen routinemäßig Karteileichen. Wenn von einem Kunden fünf Jahre lang weder Prämien noch irgendwelche Mitteilungen eingegangen sind, werden die zugehörigen Daten aus der Datenbank entfernt. Der Datensatz jedes Kunden enthält ein Feld, in dem das Datum des letzten Zugriffs gespeichert ist. Das Bereinigungsprogramm liest dieses Datum und addiert fünf zur zweistelligen Jahreszahl. Ist das Ergebnis kleiner als das aktuelle Jahr, wird die Akte gelöscht. Wenn das Programm also im Jahre 1999 läuft, erklärt es alle Kunden, von denen man 1993 zuletzt etwas gehört hat, zu Karteileichen (93+5<99) und löscht ihre Daten. Soweit korrekt, aber wenn der letzte Zugriff 1996 war, berechnet der Computer 96+5=01 wegen der zweistelligen Darstellung; das ist kleiner als 99, so daß die Akte fälschlicherweise gelöscht wird. Das ist zwar nicht in erster Linie ein Beispiel für den Y2K-Bug, sondern für schlechtes Programmieren; aber Fehler dieser Art sind schon aufgetreten.

In anderen Situationen könnte der Y2K-Bug tödlich sein, etwa wenn ein Arzt im nächsten Jahr das Geburtsdatum eines Patienten als "16.03.00" in ein Medikamenten-Dosierungsprogramm eingibt und dieses daraufhin die Dosierung für einen hundertjährigen statt einen neugeborenen Patienten bemißt.

Soweit das Problem. Wie ist es zu lösen? Der saubere Weg besteht darin, die bestehende Software durch neue, Y2K-fähige Versionen zu ersetzen. Für eingebettete Systeme (siehe Kasten Seite 87) ist dies oftmals die einzige Lösung. Es wäre aber viel zu teuer und zu zeitaufwendig, die Abermillionen gegenwärtig laufender Computerprogramme zu ersetzen. Die Firmen versuchen daher, das, was sie haben, irgendwie auszubessern.



Was ist ein Datum?



Beim ersten Auftreten des Problems war man alsbald mit einer theoretisch einfachen, legitimen und sogar optimalen Lösungsstrategie bei der Hand: Wenn zwei Ziffern fehlen, füge sie einfach hinzu! Das läuft bei einem multinationalen Unternehmen auf eine Mammutaktion hinaus; immerhin sind Abermilliarden von Datensätzen zu ändern. Aber davon ganz abgesehen muß man eine Jahreszahl erst einmal finden, bevor man ihr zwei Ziffern hinzufügen kann: Was genau ist ein Datum?

Man muß sich klarmachen, daß Computer nicht wissen, was die in ihnen gespeicherten Daten bedeuten. In den Feldern, die Name, Vorname, Geburtsdatum und so weiter enthalten, steckt keine Auskunft darüber, daß es sich bei dieser Ziffernfolge um eine Zeitangabe und bei jener um eine Kontonummer handelt; diese Interpretation wird vom Menschen vorgenommen. Sie steckt auch nur sehr unvollkommen in dem (menschengeschriebenen) Urtext ("Quelltext") der Programme, die diese Daten verwalten. Denn der Programmierer ist frei in der Wahl der Namen für seine Datenfelder – diese Namen spielen bei der Ausführung des Programms ohnehin keine Rolle; in den Programmen finden sich daher nachvollziehbare Namen wie GEB_DAT oder AEND_DAT neben kryptischen wie Y, R2D2 oder MICKY.

Die numerische Information selbst ist nicht viel aussagekräftiger. Man hat zwar versucht, Speicherplätze auf Datumsangaben zu durchsuchen: Wenn von sechs aufeinanderfolgenden Ziffern die ersten zwei zwischen 01 und 31, die nächsten zwischen 01 bis 12 und die darauffolgenden zwischen 00 und 99 liegen, liegt der Schluß auf eine Datumsangabe nahe. Aber das ist nicht sicher; was man für eine zweistellige Jahreszahl hält, könnte ebensogut eine Prozentangabe sein. Oft sind zweistellige Jahreszahlen auch tief in anderen Daten, wie langen Seriennummern, vergraben.

Eigens zur Lokalisierung von Datumsangaben sind Computerprogramme geschrieben worden. Die besten unter ihnen versuchen mit logischen Schlußregeln die Denkweise der Programmierer nachzuvollziehen und erzielen erstaunliche Erfolge, aber bisher hat noch keines vollkommen fehlerfrei gearbeitet.

Das Aufspüren ist nur der erste Schritt. Wenn die auf vier Stellen erweiterte Jahreszahl auch auf dem Bildschirm oder gedruckt zu sehen sein soll, muß im Layout an allen entsprechenden Stellen Platz dafür geschaffen werden. Wichtiger noch: Software, die auf die erweiterten Daten Bezug nimmt, ist ebenfalls anzupassen. Wenn bislang in einer Personaldatei der Namen des Angestellten in den ersten 30 Spalten abgespeichert ist, das Geburtsdatum in den nächsten 6 Spalten, das Gehalt von Spalte 37 bis 42 und so weiter, verschieben sich durch die vierstellige Schreibung des Geburtsjahres die Gehaltsangabe und alle folgenden Daten um zwei Spalten nach rechts. Alle Programme, die diese Datei benutzen, müssen entsprechend umgestellt werden.

Der Quelltext, der in einer Programmiersprache wie COBOL oder C geschrieben ist, muß also geändert und dann compiliert, das heißt in eine Form gebracht werden, die der Computer verstehen kann. Nun werden Compiler ständig verbessert, und es kommt durchaus vor, daß Programmiertechniken, die ein älterer Compiler noch akzeptierte, von der neuen Version zurückgewiesen werden, ähnlich wie Version 5 eines Textverarbeitungsprogrammes ein unter Version 3 erstelltes Dokument nicht mehr verarbeiten kann. Häufig genügt es also nicht, den alten Quellcode Y2K-fähig zu machen; man muß ihn auch noch dem Stand der Compilertechnik anpassen.

Wenn man ihn überhaupt noch findet. Im Durchschnitt gehen zwar nur etwa drei bis vier Prozent aller Quellcodes verloren, aber jeder Einzelfall ist sehr unangenehm. Der Programmierer muß entweder das Programm von Grund auf neu schreiben (was nicht einfach ist, weil die zugehörige Dokumentation in der Regel mit verlorengegangen ist) oder versuchen, den Quelltext aus der ausführbaren Version (dem Objektcode) zu rekonstruieren – eine abscheuliche Arbeit, vergleichbar der Aufgabe, aus Würsten das Schwein wiederherzustellen.

Der zeitaufwendigste Teil der Arbeit ist jedoch weder das Reparieren des Quellcodes noch das Compilieren, sondern das Austesten und das Korrigieren der neuen Fehler, die sich unvermeidlich bei jeder Änderung von Software einschleichen.

Am Anfang der neunziger Jahre waren viele Experten der Ansicht, daß eine Erweiterung des Datumsformats die beste Lösung des Y2K-Problems sei. Man hatte sich nicht klargemacht, daß jedes Programm, das auf solche Daten zugreift, neu compiliert werden muß, selbst wenn es gar keine Berechnungen mit dem Datum anstellt. Dadurch wurde dieses Vorgehen für viele Unternehmen zu teuer und zu langwierig.

Übrigens löst auch die Erweiterung auf vier Stellen das Problem nur vorübergehend. Spätestens im Jahre 9999 werden wir ein Y10K-Problem haben; aber das ist Thema eines späteren Artikels.

Wenn man aus Kostengründen die Welt der Daten nicht verändern kann, muß man sich damit begnügen, sie anders zu interpretieren. Man weist den Computer an, "00" nicht als 1900, sondern als 2000 zu lesen, entsprechend "01" als 2001 und so weiter. Diese einfache Idee, zu einem Verfahren weiterentwickelt, heißt windowing ("Fenstern"): Man legt gewissermaßen ein 100 Jahre breites Fenster (zum Beispiel 1945 bis 2044) über die Zeitachse und interpretiert alle Jahresdaten in dieses Fenster hinein. Alle Jahreszahlen nach einem sorgsam gewählten Basisjahr (im Beispiel 45) werden dem laufenden Jahrhundert zugerechnet (68 wird 1968), alle kleineren dem nächsten Jahrhundert (13 wird 2013).

Mit diesem Prinzip kann ein Programmierer alle Datumsberechnungen in einem Quellcode aufspüren und die Änderung einbauen. Weil nur die Berechnungen, nicht aber die zweistelligen Jahreszahlen selbst geändert werden, erfordert dieses Verfahren viel weniger Aufwand als eine Formaterweiterung. Gegenwärtig ist dies die meistverwendete Methode zur Y2K-Korrektur.

Windowing hat aber auch seine Schwächen. Wenn in einem System mit Basisjahr 45 ausnahmsweise doch einmal die 43 als 1943 zu verstehen ist, muß der Programmierer dafür besonderen Aufwand treiben. Offensichtlich versagt Windowing für Datumsangaben, die mehr als 100 Jahre umspannen, wie Geburtsdaten und Laufzeiten langfristiger Pachtverträge. Wenn Daten zwischen Systemen mit verschiedenen Basisjahren ausgetauscht werden, kann es interessante Effekte geben. Für ein 1928 gegründetes Unternehmen mag das Basisjahr 25 angemessen sein; wenn aber ein Programm im gleichen Betrieb, das langfristige Marktprognosen anstellt, mit Basisjahr 70 arbeitet, wird das Jahr 1931 plötzlich zum Jahr 2031 und umgekehrt, wodurch der größte Unfug entstehen kann.

Hinzu kommt, daß verschiebbare Zeitfenster in Gebrauch sind. Für ein Programm, das Hypotheken mit 30 Jahren Laufzeit handhabt, ist es sinnvoll, das Basisjahr auf 40 Jahre nach heute (oder 60 Jahre davor, was dasselbe ist) zu legen. Jedes Jahr wandert also auch das Basisjahr, und es kann vorkommen, daß ein Programm mit festem und eines mit beweglichem Zeitfenster, die im letzten Dezember noch reibungslos zusammenarbeiteten, seit diesem Januar einander gelegentlich mißverstehen – ohne verändert worden zu sein.

Ein drittes Verfahren bedient sich schlichter Arithmetik, um Y2K zu überlisten. Nehmen wir die Berechnung 00-99=-99. Falls damit 2000-1999 gemeint war, ist das Ergebnis offensichtlich falsch. Es ist aber andererseits 00-99 gleich (00+5)-(99+5), und in zweistelliger Arithmetik – das heißt unter Ignorierung der Hunderterstellen – ist das nichts anderes als 5-4=1. Die Addition von 5 zu beiden Jahreszahlen hat sie ins gleiche Jahrhundert verschoben, so daß selbst bei Benutzung von nur zwei Stellen das richtige Ergebnis herauskommt.

Ein Datum besteht jedoch nicht nur aus Zahlen: Der 1. Januar 2000 ist ein Samstag, der 1. Januar 2005 nicht. Die Addition von 5 ist also unzweckmäßig für Programme, die zwischen Wochentagen unterscheiden müssen. Aber das Problem ist lösbar: Da die Woche sieben Tage hat und alle vier Jahre ein Schaltjahr ist, kehrt das Muster der Wochentage alle 28 Jahre genau wieder (zumindest bis zum Nicht-Schaltjahr 2100). Der 1. Januar 2000 ist also derselbe Wochentag wie der 1. Januar 1972 und der 1. Januar 2028, nämlich ein Samstag. Das nutzt man nun aus, indem man 28 zu allen Jahreszahlen addiert, bevor man irgendwelche Berechnungen anstellt, und am Ende wieder 28 subtrahiert. Die Technik heißt encapsulation ("Einkapselung"): Alle Berechnungen finden nur innerhalb einer geschlossenen Zelle statt, deren Eingänge (28 addieren) und Ausgänge (28 subtrahieren) sorgfältig bewacht werden.

Dieses Verfahren ist zwar geeignet, viele Y2K-Probleme zu umgehen, für komplexere Berechnungen jedoch zu unhandlich. Wenn beispielsweise mehrere Programme häufig Daten untereinander austauschen, müßte jedes Jahresdatum aus der Kapsel des absendenden Programms heraus- und in die des empfangenden hineinbefördert werden. Oder man definiert die Kapsel so, daß sie beide Programme überspannt, und droht dadurch vollends den Überblick zu verlieren.

Encapsulation versagt außerdem, wenn Jahreszahlen mit anderen Informationen verknüpft sind. Typischer Fall ist die Lagerhaltungsnummer eines Produktes, etwa 7289-47-99-5, wobei die Jahreszahl 99 für das Verfallsdatum steht und die Fünf am Ende eine Prüfziffer ist – hier die letzte Ziffer der Summe 7289+47+99=7435. Prüfziffern stecken in zahlreichen Nummern, vor allem Kreditkarten-Nummern und den Strichcodes auf zahllosen Produkten, um Ablesefehler – oder auch Fälschungen – zu entdecken. Nach der Addition von 28 zu zweistelligen Jahreszahlen stimmt natürlich keine Prüfziffer mehr.

Diese drei Methoden – Datumserweiterung, Windowing und Encapsulation – machen mehr als 95 Prozent aller erfolgreichen Y2K-Reparaturen aus. Einige Großunternehmen mit Tausenden von Computern verwenden mehrere Verfahren zugleich, und alle drei sind durch Programme automatisierbar – von denen allerdings keines ganz ohne Fehler arbeitet.

Das Problem ist paradoxerweise auch deswegen so schwierig, weil zahlreiche Programmierer es bereits frühzeitig zu lösen versuchten. In manchen Programmen stecken bereits Basisjahre oder Zeitverschiebungen; aber diese Vorsichtsmaßnahmen sind nicht immer konsequent durchgeführt oder dokumentiert. So ist es manchmal schwierig zu entscheiden, ob überhaupt Korrekturen vorgenommen wurden. Ich selbst habe schon stundenlang vor einem Dutzend Programmzeilen gesessen und gerätselt, was das Programm eigentlich bezwecken soll. Auch automatische Reparaturprogramme bringen ihre Korrekturen häufig blindlings und ohne Verständnis für die eigentliche Funktion des Codes an. Und doppelte Zeitfenster mit verschiedenen Basisjahren, auf die möglicherweise noch Kapselung angewendet wird, können den größten Wirrwarr erzeugen.

Es gibt noch mehr Fallstricke. Früher war es üblich, Jahreszahlen in der Nähe von 2000 mit besonderer Bedeutung zu versehen. Insbesondere war 9999 oder 99 in vielen Programmen ein Kennzeichen für das Ende einer zu löschenden oder zu archivierenden Datei. Ein solches Programm zur Verwaltung von Kauf- oder Verkaufsaufträgen versteht also eine 99 im Feld für die Jahreszahl als die Anweisung, den zugehörigen Auftrag zu löschen – unzweckmäßig für die Eingabe von Aufträgen im Jahre 1999. Sämtliche derartigen Programme mußten umgeschrieben werden – was anscheinend gelungen ist: Selbst am 9. September dieses Jahres (9. 9. 99) wurden keine besonderen Computerkatastrophen gemeldet. Deren Ausbleiben war mehreren amerikanischen Tageszeitungen immerhin eine eigene Meldung wert.

Es könnte auch sein, daß das Jahr 2000 in manchen Computern nicht als Schaltjahr einprogrammiert ist: Immerhin handelt es sich um die Ausnahme (alle 400 Jahre doch ein Schaltjahr) von der Ausnahme (alle 100 Jahre kein Schaltjahr) von der Ausnahme (alle vier Jahre ein Schaltjahr). Es ist nicht abwegig zu vermuten, daß dieses Ereignis, das zum nächsten Mal erst 2400 eintreten wird, nicht in allen Programmen korrekt berücksichtigt worden ist.



Droht die Katastrophe?



Diese und andere Faktoren haben zu hitzigen Debatten über Y2K geführt. Das Spektrum reicht dabei von schierem Schwachsinn "Es besteht die Gefahr, daß wir für immer die Stromversorgung verlieren werden" (so allen Ernstes kürzlich ein Sprecher auf einer Y2K-Tagung) bis zu verfehlter Verharmlosung: "Y2K ist eine Eintagsfliege. Alle Probleme werden übers Wochenende gelöst werden."

Ich halte beide Extremansichten für gleichermaßen naiv. Die erste ignoriert die Fähigkeit der Gesellschaft, mit widrigen Umständen fertig zu werden. Die Aussage, daß die Menschheit für immer unfähig zur Erzeugung von Elektrizität werden könnte, ist keiner ernsthaften Diskussion würdig. Im Gegenteil: Große Organisationen, vor allem Banken und Börsen, widmen sich der Bewältigung des Problems mit großem Aufwand und, soweit bisher sichtbar, mit Erfolg: Verschiedene Organisationen haben die Kalender ihrer Computer probeweise auf das nächste Jahr vorgestellt und dabei nur wenige datumsbezogene Probleme aufgespürt.

Andererseits: Wer Y2K verniedlicht, ignoriert, wie empfindlich unsere moderne Gesellschaft von dem reibungslosen Funktionieren komplexer technischer Netze abhängt. Vereinzelte Fehlfunktionen können sich schnell und mit katastrophalen Folgen in diesem System ausbreiten. Ein Defekt des Kommunikationssatelliten Galaxy IV im Frühjahr 1998 machte Millionen von Kleinempfängern (Pagern) zu Schrott. Ein defektes Kabel verursachte eine Systemüberlastung in Auckland (Neuseeland), woraufhin die Stadt für sechs Wochen ohne Strom war.

Keiner dieser Zwischenfälle war voraussehbar – im Gegensatz zu Y2K. Programmierer auf der ganzen Welt sind heute dabei, ihre Software zu modifizieren. Die CIBC-Bank in Kanada beschäftigt tausend Mitarbeiter mit diesem Problem und gibt dafür 120 Millionen Dollar aus. Die Telephongesellschaft AT&T hat schon über 500 Millionen Dollar ausgegeben, und die Steuerbehörde der USA rechnet mit einer Milliarde.

Das ist sehr viel Geld; aber die Erfahrung lehrt uns, daß dieses Geld wahrscheinlich gut angelegt ist. Große Softwareprojekte werden höchst selten termingerecht fertig, und wenn, dann sind sie oft fehlerbehaftet. Man denke an die Olympischen Spiele in Atlanta oder den neugebauten Flughafen von Denver, der wegen Softwarefehlern in der Gepäckbeförderung über ein Jahr lang nicht in Betrieb gehen konnte (Spektrum der Wissenschaft, Dezember 1994, S. 56). Dummerweise ist bei Y2K der Termin nicht verschiebbar.

Die Größe des Problems, die bisher getroffenen Vorkehrungen, der Termindruck und der daraus resultierende Zwang zum faulen Kompromiß, Erfahrungen mit früheren Großprojekten: Wenn man dies alles in Betracht zieht, was ist dann eine vernünftige Prognose? Nach meiner Einschätzung werden wir etwa einen Monat lang mit schweren Zwischenfällen rechnen müssen. Kleinere bis mittelgroße Ärgernisse werden uns das ganze Jahr 2000 hindurch begleiten. Das ist vielleicht noch zu optimistisch. Meine Prognose beruht auf der Annahme, daß alles Mögliche getan wurde, um individuelle Schwachstellen zu eliminieren. Das allein ist bereits eine Herkulesarbeit, die in der Geschichte des Computers ihresgleichen sucht.

Literaturhinweise


The Year 2000 Software Crisis: Challenge of the Century. Von William M. Ulrich und Ian S. Hayes. Prentice Hall, 1997.

Countdown Y2K: Business Survival Planning for the Year 2000. Von Peter de Jager und Richard Bergeon. Wiley, 1998.

The Year 2000 Software Problem: Quantifying the Costs and Assessing the Consequences. Von Capers Jones. Addison-Wesley, 1998.

Der Zweitausend Crash. Von Martin Kunz. dtv, München 1999.

Weitere Informationen auf der Website des Autors: www.year2000.com


Aus: Spektrum der Wissenschaft 11 / 1999, Seite 84
© Spektrum der Wissenschaft Verlagsgesellschaft mbH