Jaro's Techno-Ecke: Das Millenium Debakel Mittlerweile hat wohl ein jeder mitbekommen, daß der Übergang in das Jahr 2000 etwas besonderes ist. Nicht nur weil dann das neue Jahrtausend nicht beginnt, sondern weil es das wohl auch mit einem grossen Knall tun wird. Dieses anstehende Großereignis wird gemeinhin mit "Y2K" (Year 2 K, K = Kilo = 1000) oder auch als "Millenium Bug" bezeichnet. Ursache für die Y2K Euphorie sind lausige und schlampige Designer, Entwickler und Tester von Software die in den letzten Jahrzehnten entwickelt wurde. In früheren Zeiten waren Softwareentwickler nicht nur auf ständiges optimieren bedacht (der heutige Trend geht ins Gegenteil), sondern haben auch jedes mögliche Bit und Byte für schlechtere Zeiten eingespart. Und so wurde in einer großen Menge Software die Jahrangabe des Datums nur mit zwei Stellen kodiert; also z.B. "98" anstatt "1998". So zu finden nicht nur in Eingabemasken, sondern auch in internen Berechnungen; z.B. der Ermittlung des Alters einer Person (Alter = Datum heute:98 minus Geburtsjahr:63 = 35). Die Entwickler haben entweder zu wenig nachgedacht oder nicht erwartet, daß die Applikationen längere Zeit im Gebrauch sein würden. Denn sobald man das Jahr 2000 erreicht, fallen alle Rechnungen nach obigem Muster auf die Nase (Alter = Datum heute:00 minus Geburtsjahr:63 = -63). Und das ist nur einer der einfachsten Fälle. Einige Beispiele für potentielle Folgen sind: Bestände in automatisierten Lagern werden automatisch weggeworfen, da das Verfallsdatum plötzlich seit z.B. 63 Jahren abgelaufen ist. Rendite-, Zins- und Schuldberechnungen sind falsch. "Intelligente" Geräte (z.B. Aufzüge) verweigern den Dienst, da Wartungsintervalle abgelaufen sind. Greise werden zum Militärdienst einberufen. Und man muß die Stromrechnung für die letzten 100 Jahre nachzahlen. Wahrscheinliche Szenarien gibt es viele. In vielen Regierungen (siehe z.B. US Presidential Executive Order "Year 2000 Conversion", bereits (!?) vom 4. Februar 1998) und Unternehmen, insbesondere im Geldsektor, ist man inzwischen aufgewacht und beginnt die vorhandene Software zu inspizieren, potentielle Problemherde zu lokalisieren und Lösungen zu finden. Dazu gehört z.B. auch die hektische Umtauschaktion vieler Kredit- und EC-Karten mit dubiosem Enddatum (01/00 o.ä.) durch die Banken. Der Bedarf an Unterstützung geht soweit, daß jeder verfügbare Programmierer (zum Teil aus der Rente) wieder angeheuert wird, um den alten Kram zu reparieren. Jedoch - warum soll man den Leuten bei der Reparatur trauen, die den Fehler ursprünglich im großem Rahmen verursacht haben? Zudem wurde erkannt, daß im Normalfall keine Chance besteht die Unmenge betroffener Software rechtzeitig zu reparieren und - noch viel wichtiger - zu testen. So konzentriert man sich auf die geschätzt 20% "Mission Critical" Applikationen und wird kurz vor Silvester 1999 heftig die Augen schließen und hoffen. Da teilweise die Auswirkungen einer größeren Softwareänderung auf die Gesamtfunktion gar nicht analysierbar sind, ist eine der beliebtesten Scheinlösungen die 80/20-Regel: Man fummelt die Software so, daß sie im Zweifelsfall 80 Jahre zurück und 20 Jahre voraus zu raten versucht! Beispiel: Es ist das Jahr 2002: Jemand gibt in seine (2-stellige) Maske das Jahr 17 ein. Dann geht die Software davon aus, daß man innerhalb des 20-Jahre Intervalls nach vorne plant und rechnet mit dem Jahr 2017. Analog rechnet das Programm bei Eingabe von 24 mit dem Jahr 1924. Daß dies allerhöchstens gefährliche Augenwischerei ist, sieht man direkt. Warum aber verdienen sich die Berater mit dieser und ähnlichen Methoden eine goldenen Nase? Was viele Y2K-Bearbeiter zudem vergessen ist, daß wir 24 Zeitzonen auf der Erde haben. Durch die globale Vernetzung vieler Systeme werden sich Fehler und Zusammenbrüche eventuell weltweit fortpflanzen und vermehren. Man stelle sich vor, bei einer verteilten Computer- Transaktion ist es in USA am 31.12.1999 19:00 Uhr, während der Zeitstempel dieser Transaktion in Europa z.B. als 01.01.1900 01:00 interpretiert wird. Sechs Stunden später, aber 100 Jahre zurück. Noch schlimmer als bei der weichen Ware wird sich das Problem bei "Embedded Systems" zeigen. Dies sind Geräte mit eingebauten Computerchips, die intern irgendwelche (ja welche denn?) Kalkulationen ausführen. Nun gibt es diese Chips in Autos (Berechnung der Wartungsintervalle, Steuerung der Zündung), Flugzeugen (Steuerung von so ziemlich allem) und darüber hinaus in jedem komplexeren elektrisch betriebenen Gerät. Ärgerlich ist, daß man nicht weiß wie die Chips programmiert sind, was sie mit dem Datum anstellen werden und wie man sie denn auswechseln soll, falls man überhaupt den Hersteller identifiziert und von ihm korrekte (?) Ersatzteile bekommt. Der Millenium Bug ist der bekannteste Vertreter einer unglaublichen Serie von Schlampigkeiten, aber es gibt noch andere datumsbezogene Malheurs die uns Dank unbegabter Programmierer bevorstehen: Schaltjahr 2000? Der 29. Februar 2000 existiert; in vielen Programmen allerdings nicht. Die meisten Entwickler wissen, daß alle vier Jahre ein Schaltjahr stattfindet. Viele wissen, daß dies in Jahren die durch 100 teilbar sind nicht so ist. Aber kaum einer wußte, daß in Jahren die durch 400 teilbar sind doch ein Schalttag kommt. Also wird viel Software den 29. Februar nicht kennen und ab dann furchtbar durcheinander geraten. Klevere Kodierungen: Vielfach braucht man in Programmen besondere Datenkodierungen die eine Steuerungsfunktion haben. So könnte man z.B. durch Eingabe von "9999" eine Transaktion abbrechen. Dummerweise könnte das System dies aber auch als 9. September 99 interpretieren (oder umgekehrt). Erfahrungsgemäß sind Entwickler beim basteln von Kodierungen sehr kreativ und man wird an etlichen Tagen lustige Effekte in seiner Software erwarten können. GPS benutzt zur Kodierung seiner internen Zeit, die essentiell für die Berechnung der Position ist (siehe Techno-Ecke 1), eine Kombination von GPS-Woche (Anzahl der Wochen seit dem 6. Januar 1980 00:00 Uhr) und der Anzahl der 10-Nanosekunden in dieser Woche. Die Wochenzahl wird mit 10 Bit kodiert, was 1024 Wochen und einem Überlauf am 22. August 1999 00:00 Uhr entspricht. Da dies in der GPS Spezifikation (dünn) dokumentiert ist, werden die Satelliten das richtige tun. Viele Empfänger am Boden und in Flugzeugen sind aber schlampig programmiert, behandeln den Fall nicht korrekt und werden ab obigem Datum eine katastrophal falsche Zeitangabe in ihre Gleichungen reinstecken. Garbage-in, Garbage out. Unix Date-Overflow: Ältere Computer Betriebssysteme der Unix-Familie berechnen das Datum in Sekunden seit dem 1. Januar 1970 00:00 Uhr ("Epoch" genannt). Da diese Unixe nur 32-bit lange Zahlen verwenden, wird das interne Datum am 19. Januar 2038 03:14:07 Uhr auf Null überlaufen. (Für Nachrechner: 31 Bit + Vorzeichen!) Alle Programme die Zeitangaben verwenden, werden dann ein echtes Problem haben. Bis dahin ist es aber noch lange hin. Die kleine Liste von Beispielen soll andeuten, wie viele Probleme wir eventuell in rund 18 Monaten zu erwarten haben. Die Zwangs-Einführung des Euro, die ja auch massive Softwareänderungen erfordert, zu solch einem Zeitpunkt kann man nur als bodenlose Dummheit betrachten. Und noch ein paar kleine, aber ernstgemeinte Tips: Um den 22. August 1999 herum würde ich nicht fliegen. Und an Silvester 1999 (glücklicherweise ein Freitag) werde ich mit einem Arsenal Öllampen, genug Lebensmitteln und Bargeld brav zu Haus sitzen und schauen was dem Rest der Zivilisation passiert, der sich auf E-Werke, EC-Automaten und Supermarktkassen verläßt. Euer JARO