Jahrtausendwechsel und andere Kleinigkeiten

"Ein Unternehmen, das heute noch nicht angefangen hat, wird es nicht schaffen." Dieser schicksalsschwere Satz eines Commerzbank-Managers bezieht sich nicht etwa auf den Strukturwandel, neue Führungspraktiken oder die Anpassung an den globalen Wettbewerb, keineswegs; sein feierlicher Ernst bezieht sich vielmehr auf ein Problem, das auf den ersten Blick ein schlechter Scherz zu sein scheint: Tausende von Computerprogrammen scheitern an der Jahrtausendwende in vier Jahren. Warum? Nun, sie speichern die Jahreszahl einfach in zwei Zeichen ab, etwa "96". Das Jahr 2000 erscheint also als "00". Bei der Berechnung von Habenzinsen (sagen wir: 5%, 5000 DM) für ein Jahr könnte dies bedeuten: Da 00 - 99 -99 beträgt, werden dem Kunden einer Bank im Jahr 2000 nicht etwa 250 DM gutgeschrieben, sondern 621.196,47 DM Schuldzinsen (inklusive Zinseszinsen) berechnet. Uff! Grund für dieses überraschende Problem, dessen Behebung nach den pessimistischsten Schätzungen etwa 60 Milliarden DM kosten wird, ist die Tatsache, daß Computerprogramme seltener als angenommen gewechselt werden. Warum auch? Wenn ein COBOL-Veteran aus den sechziger Jahren (als man an den Jahrtausendwechsel noch gar nicht dachte) klaglos funktioniert und dank laufend verbesserter Rechnertechnik auch passabel schnell läuft, besteht für einen Wechsel kein Anlaß. Die Mitarbeiter sind eingearbeitet, das Programm ist an seinen speziellen Zweck optimal angepaßt. Trotzdem muß den interessierten Laien das Problem wundern. Die Unternehmen (die Commerzbank beschäftigt für sie Umstellung 30 Leute, die Allianz redet von 10 Mannjahren) behaupten, damals seien wegen des knappen Speicherplatzes nur zwei Ziffern gespeichert worden. Doch jede Ziffer beansprucht 1 Byte Speicherplatz im ASCII-Code. 1 Byte kann aber, so haben wir's im Pascal-Grundkurs gelernt, eine Zahl zwischen 0 und 255 darstellen. Man hätte also damals, wenn man schon Speicherplatz sparen wollte, das Jahr binär in nur einem Byte speichern können. Hätte man es im Programm mit 1900 addiert, wäre das Problem erst im Jahr 2156 aufgetreten. Speichert man ein komplettes Datum im ASCII-Code, also etwa "010396" (1.3.1996), so sind das schon 6 Byte. Dabei ließen sich schon in 4 Byte jedes Datum völlig zukunftssicher ablegen, indem man das Jahr voranstellt und den Tag hintansetzt: 19960301 läßt sich binär als Long Integer speichern, dessen maximale Größe bekanntlich 232-1 beträgt und folglich Platz bis zum Jahr 429496 hat. Die nötigen Konvertierungen dürften heute einen aufgeweckten Neunjährigen mit Pascal- oder BASIC-Grundkenntnissen vor keine Probleme stellen. Wahrscheinlich schien damals der Aufwand zu groß, die ASCII-Zeichen aus den Eingabemasken in Binärzahlen zu konvertieren und umgekehrt. Doch hat diese Episode, ähnlich wie der Pentium-Rechenfehler oder die behördliche Mahnung an einen 106jährigen, sich endlich einschulen zu lassen (der Computer konnte wie oben nur bis 99 zählen), etwas Tröstliches. Die Rechenknechte werden zwar immer perfekter, aber sie sind trotzdem von A bis Z menschliche Erfindungen mit menschlichen Fehlern. (Auf die man allerdings getrost verzichten kann.) Ein weiteres Fiasko droht: Ist das Jahr 2000 nun ein Schaltjahr? Scheinbar ja, denn es ist ohne Rest durch 4 teilbar. Doch wenn ein Jahr durch 100 teilbar ist, gilt dies nicht _ mit einer Ausnahme: Es muß ohne Rest durch 400 teilbar sein. Mit anderen Worten: Das Jahr 2000 ist das erste Schaltjahr, das glatt durch 100 teilbar ist, seit dem Jahr 1600. Trotzdem sollte man sich für dem 29.2.2000 keine allzu wichtigen Termine wie etwa Geburt, Hochzeit oder Kredittilgung vornehmen. Es könnte sein, daß man vom Computer vergessen wird. G.D.