Zeitbombe

Inhaltsverzeichnis

Noch 360 Tage bleiben bis zum magischen Datum 1. Januar 2000. [1] Die letzte Frist ist angebrochen, Fehler zu suchen und auszumerzen oder immerhin ihre Auswirkungen zu begrenzen. Kraftwerke und Krankenhäuser sind ebenso betroffen wie PC-Systeme. Doch alle Auguren tappen im dunkeln. Welche Hard- und Software wird tatsächlich lahmgelegt? Welche Systeme verarbeiten Daten jenseits vom 31. Dezember 1999 nicht korrekt? Anwender und Hersteller fahnden nach Bugs - und werden fündig ...

Eine klare Auskunft vom Hersteller erhielt die Notrufzentrale in Hannover: Die Software des Rechners, der die Gefahrenpunkte kennt und die Einsätze der Feuerwehr koordiniert, ist nicht 2000-fest. Ohne Update müßten die Beamten wieder Bleistift und Papier zücken und den Stadtplan wälzen.

Alan Greenspan, einst Entwickler und nun der Vorsitzende der US-Zentralbank, mahnte vergangenen September vor einem Kongreßkomitee: `Ich erinnere mich nicht daran, eine nennenswerte Dokumentation zu den Programmen gehabt zu haben, die ich schrieb. Und es kam uns nie in den Sinn, daß diese Programme, welche die Eins und die Neun [...] weglassen, immer noch laufen, wenn wir uns dem Jahrtausend nähern.´ [2]

In Europa spürt man schon ein Jahr eher, was 2000 bringen kann, denn die Umstellung auf die gemeinsame Währung zieht vergleichbare Fehler nach sich. Die Banken müssen Buchungen in Euro anbieten - der Privatkunde merkt´s an streikenden Geldautomaten und an Störungen bei der PC-Kontoführung (siehe c't 1/99, S. 82). Viele multinationale Unternehmen haben bereits umgestellt; sie drängen ihre meist schlechter vorbereiteten Zulieferer, Rechnungen in Euro zu stellen. Wie viele davon per Taschenrechner statt per Computer umgerechnet werden, stellt sich in den nächsten Wochen heraus. Gemäß diversen Umfragen gönnen sich die meisten kleinen und mittleren Firmen lieber die knapp drei Jahre Zeit bis zum Ende der D-Mark.

Fleißige Vielbeiner

Rechner mit Maus und Monitor machen nur einen Bruchteil des Computerbestands der Erde aus. Millionen unscheinbarer Mikroprozessoren stecken in Videorecordern und Limousinen, in Herz-Lungen-Maschinen, Atomraketen und Atomreaktoren. Manche Beobachter vermuten die größte Jahr-2000-bedingte Gefahr durch solche Steuerungssysteme (Embedded Systems). Es gibt davon wesentlich mehr als von den `richtigen´ Computern (Zählen Sie mal in ihrem Haushalt nach ...), aber die Gesamtzahl läßt sich schwer fassen: Gilt ein Flugzeug als ein System oder als 1000 Systeme? Embedded Systems sind meist schlecht zu testen oder zu warten. Wie spielt man ein Softwareupdate in einen Videorecorder ein?

Boeing nennt einige Flugmanagementsysteme, die am 1. Januar 2000 fälschlicherweise warnen werden, daß ihre Daten veraltet sind. General Electric Medical Systems meldet zum medizinischen Ultraschallgerät RT 5000: Versagt die Speicherschutzbatterie gerade im Jahr 2000, muß die Prozessorplatine ausgetauscht werden. Solche Fehler sind ärgerlich, aber nicht unmittelbar gefährlich. Wenig Trost spendete uns ein Entwickler: `Embedded-Programme werden in der Regel mit heißer Nadel gestrickt.´

Wer wie Bernd Sporleder, der Jahr-2000-Beauftragte der Stadt Hannover, erst einmal auf die Suche nach Embedded Systems geht, erlebt manche Überraschung: In den Drehleitern der Feuerwehrfahrzeuge sitzen Rechner, die jede Bewegung mit Uhrzeit und Datum protokollieren. Noch wartet Sporleder auf eine Meldung vom Hersteller, ob diese Leitern vielleicht einen Einsatz am 1. Januar 2000 verweigern und statt dessen auf einer turnusmäßigen Wartung beharren, weil seit der letzten scheinbar 99 Jahre vergangen sind. Ausprobieren kann er das nicht ...

Wir sind diversen Berichten über gefährliche Fehler etwa bei der Medizintechnik nachgegangen, mußten aber feststellen, daß die Spuren sich als Gerücht herausstellten oder daß Leute, die es wissen müßten, nichts Genaues über Zahl und Art der Fehler sagen wollten. `Selbst wenn wir bis jetzt noch nichts gefunden haben, heißt das ja nicht, daß wir nicht noch was finden könnten´, so Professor Porth von der Medizinischen Hochschule Hannover.

Beim Durchblättern der riesigen Jahr-2000-Kompatibilitätsliste der US-Behörde für Lebensmittel und Pharmazie (Food and Drug Administration) gewinnt man wieder Zuversicht [3]. Dort finden sich nur wenige Geräte mit Bugs; fast immer passiert nichts Schlimmeres, als daß die Jahrhundert- und Jahrtausendstelle der Jahreszahl verstümmelt erscheint. Die Liste basiert jedoch auf Herstellerangaben ...

Frühmerker

Vielen Firmen und Organisationen scheint die Dringlichkeit erst Mitte 98 bewußt geworden zu sein. Der Bundesfachverband Medizinprodukte hat Ende 98 den etwa 2000 Krankenhäusern in Deutschland eine Checkliste zugefaxt und bereits in den ersten Tagen über 100 teils erschrockene Rückfragen erhalten. Nicht nur kleine Firmen, selbst respektable Großkonzerne wie der Stromriese PreussenElektra beenden gerade mal ihre erste Bestandsaufnahme. `Beginnen Sie sofort!´ riet die Vereinigung Deutscher Elektrizitätswerke VDEW ihren Mitgliedern in einer Informationsbroschüre - Ende Juli 1998.

Die USA scheinen dem Rest der Welt mal wieder einige Monate voraus zu sein. So kontrolliert die US-Atomaufsichtsbehörde NRC mit Stichproben vor Ort, wie weit die Jahr-2000-Vorbereitungen in den rund 100 US-Atomkraftwerken gediehen sind. Erste Ergebnisse kann jedermann im Web einsehen. [4] Während einige Reaktoren nur unwesentliche Macken haben, meldet das Team von Block 1 des Kraftwerks Seabrook diverse Jahr-2000-Fehler: fünf von zwölf sicherheitskritischen Systemen oder Programmen sind betroffen.

Mit solchen Zahlen oder gar detaillierten Berichten hält man sich hierzulande zurück. Vom Bundesumweltministerium hörten wir nur, `daß es kein Jahr-2000-Problem in deutschen AKWs gibt.´ Die Gutachter der Gesellschaft für Reaktorsicherheit (GRS) konnten auf Anfrage bloß mitteilen, daß keine Gefahr drohe. Zwar müßten noch einzelne Meßgeräte überprüft werden, aber Reaktorschutzsysteme seien `festverdrahtet´ und damit nicht betroffen. Welche Tests denn gelaufen sind, konnten aber weder die GRS noch der Hersteller Kraftwerksunion (KWU) verraten.

Fachleute unterscheiden fein zwischen Sicherheitsleittechnik und Betriebsleittechnik. Die Aussagen von GRS und BMU genügen also nicht für eine Entwarnung. Denn selbst wenn schwerwiegende Störfälle ausbleiben, kann der Kraftwerksbetrieb bis zum Abschalten beeinträchtigt werden. Und auch Fehler in Systemen, die auf den ersten Blick weniger kritisch sind, könnten theoretisch zur Katastrophe führen. Vielleicht fällt eine Klimaanlage aus, wodurch sich ein wichtiger Prozeßrechner überhitzt, oder ein scheinbar unwichtiger Datenrecorder zeichnet unsinnige Werte auf, so daß die Bedienmannschaft falsche Entscheidungen trifft.

Unter Strom

Die Stromverteiler sind genauso betroffen wie die Stromerzeuger. Im März 1998 haben die Stadtwerke Hannover ihr Netzwerkleitsystem und damit auch die Umspannwerke testweise mit dem Datum 1. Januar 2000 betrieben. Resultat: Der Zentralrechner hätte nach einem Ausfall nicht mehr hochgefahren werden können. Ein solcher Fehler würde im Ernstfall zwar nicht sofort zu Stromausfällen führen, auf geänderte Verbraucherlast oder auf Störungen im Netz hätte man danach aber per Handbetrieb reagieren müssen.

Nach einem Bugfix wurde das Hannoveraner Experiment im Oktober wiederholt. Fast zwei Wochen lang lief das gesamte Netzwerkleitsystem nahezu fehlerlos. Nur ein Leitungsbruch offenbarte einen weiteren Bug - ausgerechnet im Störungsfall wurden fehlerhafte Routinen benutzt, die den Programmierern beim ersten Mal durch die Maschen geschlüpft waren.

2000 zu Hause

Gegen das, was Firmen und Verwaltungen an Jahr-2000-Pannen entdecken, dürften die Probleme des heimischen PC-Anwenders eher harmlos sein. Einige müssen am 1. Januar 2000 gegebenenfalls die Systemuhr auf das korrekte Datum stellen (siehe c't 1/99, S. 66). Die Fehler in den gängigen Betriebssystemen und Anwendungsprogrammen fallen größtenteils in die Kategorie `Exotisches´ (siehe c't 1/99, Seite 70).

Sollte aktuelle, weitverbreitete PC-Software Fehler zeigen - ob schon jetzt oder erst nächstes Jahr -, gehen die Meldungen darüber binnen Stunden um die Welt. Obendrein führen zumindest einige Großanwender und öffentlichkeitshungrige Berater in eigenem Interesse Tests durch. Die Hersteller geben sich Mühe, gefundene Fehler schnell zu beseitigen, sind sie sich doch der negativen Propaganda bewußt.

Weniger verbreitete Software birgt ein größeres Risiko, daß Jahr-2000-Fehler zu spät auffallen - wenn etwa die Software bereits Datenbanken teilweise überschrieben oder falsche Rechnungen verschickt hat. Zu wenige freiwillige Tester fahnden bei den selteneren oder älteren Programmen nach Bugs, zu klein ist der Druck der Öffentlichkeit. Firmeneigene PC-Programme, selbstgeschriebene Datenbanken oder Makros muß man sowieso selbst testen.

Abgeschnitten

Den Grund für den Ärger mit dem Jahr 2000 hat mancher Beobachter schnell ausgemacht: Die Entwickler mußten vor 15 Jahren mit Speicherplatz geizen und haben deshalb die `19´ vor der Jahreszahl nicht gespeichert, so die übliche Theorie. Das klingt einleuchtend, aber die volle Wahrheit liegt auf halber Strecke zwischen Tradition und Schlamperei.

Die Jahresangabe 98 sollte man nicht als Folge der zwei ASCII-Zeichen `9´ und `8´ im Speicher ablegen. Denn der Computer rechnet nicht mit Ziffern von 0 bis 9, sondern im Binärsystem. Oft - etwa im Dateisystem von MSDOS - zählt man die Jahre ab 1980; zum Beispiel wird 1998 dann zu 18 oder binär 00010010. Auf diese Weise reicht der Speicherplatz von einem Byte für die Jahre von 1980 bis 2235. (MSDOS benutzt nur sieben Bits, was für 1980 bis 2107 reicht.)

Wenn ein Programmierer dagegen 1998 als Folge der zwei ASCII-Zeichen `9´ und `8´ speichert, belegt er zwei Byte. Leider ist den Technikern aber doch ein Patent eingefallen, wie sie zwei dezimale Ziffern kompakt in einem einzigen Byte ablegen können. Jede Ziffer für sich benötigt nur vier Bits (BCD, Binary Coded Decimal). Also speichert man die Zehnerstelle in den oberen vier Bits, die Einerstelle in den unteren vier (`gepacktes BCD´), und schon passen zwei Dezimalziffern in ein Byte.

Gängige höhere Programmiersprachen wie C++ oder Visual Basic arbeiten nicht direkt mit diesem Zahlenformat. Die Mikroprozessoren selbst verfügen aber meist über Rechenoperationen für die BCD-Darstellung; das könnte den einen oder anderen Entwickler, der mit Maschinensprache arbeitet, in Versuchung geführt haben, gepackte BCD-Zahlen den echten Binärzahlen vorzuziehen. Hier drohen Jahr-2000-Fehler, denn ein Byte faßt dann nur Werte von 0 bis 99.

Knappe Stellen

Insgesamt aber scheint unverständlich, daß ein vernünftiger Programmierer Jahr-2000-Probleme akzeptiert, um Speicherplatz zu sparen, denn erstens spart er selbst mit wilden Konstruktionen keinen Speicherplatz, und zweitens nimmt er aufwendige Rechenoperationen in Kauf.

Das gilt aber nur für die gängigen Computersysteme. Anwendungen für Versicherungen, Banken und Verwaltung entstanden im Laufe der vergangenen zwanzig Jahre in der Sprache Cobol. [5] Viele dieser über die Jahrzehnte gewachsenen Mammuts werden immer noch gepflegt; sogar neue Software entsteht heute noch in Cobol, einerseits der Kompatibilität wegen, andererseits, weil diese Sprache gute Voraussetzungen für das exakte Rechnen mitbringt.

Cobol-Variablen legt man nicht, wie heute üblich, etwa als 32 oder 16 Bit lange Binärzahlen an. Vielmehr gibt der Programmierer die Zahl der Dezimalstellen vor. Das ist sinnvoll, um sicherzustellen, daß die Software auch 18stellige Vermögenswerte ohne Überlauf oder Rundungsfehler verarbeitet. Dumm nur, wenn für eine Jahreszahl eine Variable mit zwei Dezimalstellen vorgesehen ist. Was passiert, wenn man dann das Jahr 99 um eins weiterzählt, ist nicht standardisiert.

Aber es kommt noch dicker: Standardmäßig legen Cobol-Compiler auch numerische Daten als ASCII-Zeichenketten ab. Eine vierstellige Jahreszahl belegt damit satte vier Byte. Wer noch mit Ferritkernspeicher und Lochkarten arbeitet, kommt da leicht auf den Gedanken, die Jahrhundertziffern wegzulassen. Und genau das findet man als Beispiel in fast jedem der angestaubten Lehrbücher - obwohl Cobol auch binäre oder immerhin speicherplatzsparend gepackte BCD-Variablen erlaubt.

Cobol-Tradition ist es, Datumsangaben kompakt in der Form Jahr/Monat/Tag zu speichern. Aus dem 8. Dezember 1998 wird so die Dezimalzahl 981208, im Speicher eine sechs Byte lange Zeichenkette. Trotz Geiz bei der Jahrhundertangabe bedeutet dieses Datumsformat eine fulminante Platzverschwendung. Würde man statt dessen in einer binären Zwei-Byte-Zahl die Zahl der Tage seit dem 1. Januar 1900 speichern, reichte der Kalender statt bis zum 31. Dezember 1999 bis ins Jahr 2079 - fast doppelt soviel Jahre auf einem Drittel des Platzes.

Daß jemand auf die Idee kommt, mit Datumsformaten wie 981208 zu arbeiten, scheint heutzutage abstrus. Die Standard-Funktionen in Cobol sprechen aber Bände: Das Systemdatum gab´s als sechsstellige Zahl. Heutige Cobol-Compiler arbeiten hier und bei anderen Datumsfunktionen mit achtstelligen Werten: 19981208 statt 981208.

Wenn die Aufgabe der altvorderen Cobol-Programmierer darin bestanden hätte, Speicher zu sparen, hätten sie diese Aufgabe recht dürftig erfüllt. Dafür bescheren ihre halbgaren Lösungen jetzt den einstigen Auftraggebern (und deren Nachfolgern) Kopfschmerzen ohne Ende. Die Defense Logistics Agency der US Army hat mehrere Pilotprojekte durchgeführt, in denen große Cobol-Programme mit etwa 100 000 Zeilen Umfang Jahr-2000-fest gemacht wurden. [6] Die Kosten dafür betrugen pro Zeile (!) knapp einen US-Dollar. Solche Zahlen rücken die Billionenprognosen der Analysten in den Bereich des Denkbaren (Software Productivity Research: 1,6 Billionen US-$, Cap Gemini: 860 Milliarden US-$, Gartner Group: 300 bis 600 Milliarden US-$).

Rundes Datum

Auch außerhalb der Cobol-Tradition lauern Jahr-2000-Bugs. Manche Entwickler haben sich für Sparmaßnahmen bei der Ein- und Ausgabe entschieden - und dabei die Jahr-2000-Fähigkeit geopfert. Das typische Beispiel sind Datenbankoberflächen, in die man Jahreszahlen mit nur zwei Stellen eingibt. Das geht zwar schneller, als das scheinbar unsinnige `19´ vorwegzutippen - aber wie merkt die Datenbank, daß ´05 nicht 1905, sondern 2005 bedeutet?

Seit langen Jahren sehen Entwickler in weiser Voraussicht Ein- und Ausgabe vierstelliger Jahreszahlen vor - nur wurde die Hard- und Software nicht ordentlich mit Werten jenseits von 1999 getestet. Das Phänomen kennt man in der Informationstechnik-Branche: Was nicht getestet wurde, funktioniert wahrscheinlich auch nicht, weil sich im Dunkeln unzählige Bugs verbergen. Diese Schlamperei trifft PC-Benutzer ebenso wie Banken, Energieversorger und Krankenhäuser.

Eine indirekte Folge davon, daß Dezimalzahlen für die Ausgabe benutzt werden, ist das Jahr-2000-Problem vieler PC-Systemuhren. Der Uhrenchip sollte wohl eigentlich keine Rechner versorgen, sondern ohne viel Aufwand digitale Zeitanzeigen ansteuern. Deshalb liefert er Zeit und Datum nicht binär, sondern BCD-kodiert in Dezimalziffern. Für die Jahresangabe sind nur zwei Stellen vorgesehen; das Jahrhundert-Bit muß manuell oder per Software eingestellt werden. Nur scheint mancher Hersteller das erst jüngst gemerkt zu haben ... (siehe c't Heft 1/99, S. 66)

Dieselben Fehler drohen auch den Funkuhren, die vom Normalzeitsender DCF77 gesteuert werden. Der überträgt ebenfalls keine Binärwerte, sondern nur Ziffern ohne Jahrhundertangabe. Manche Industrieanlagen nutzen statt DCF77 das von US-Satelliten ausgestrahlte GPS-Signal als Zeitnormal - eigentlich ein System zur Positionsmessung. Der GPS-Wochenzähler zählt von 0 bis 1023 und springt am 22. August 1999 auf Null zurück.

Mikroprozessor-Steuerungen mit eigenen Uhren benutzen typischerweise Chips wie den Seiko-Epson RTC-72421, der nur Jahresangaben von 0 bis 99 in Dezimalziffern liefert; die Jahrhundertangabe fehlt. Unterhaltungselektronik oder Telefontechnik wird heute oft in der I2C-Bus-Technik aufgebaut. Der Philips PCF-8583, ein gängiger Uhrenchip dafür, liefert nur Stunden, Minuten und Sekunden, aber keine brauchbare Jahresangabe. Die Entwickler müssen die Jahreszahl selbst generieren, hoffentlich dann binär statt mit zwei Dezimalstellen.

366 Tage

Das Jahr 2000 ist wie schon das Jahr 1996 und das Jahr 2004 ein Schaltjahr. Eigentlich kein Wunder, sollte man meinen - alle vier Jahr kommt ein Schaltjahr. Leider nicht immer: Damit die Jahreszeiten nicht im Kalender verrutschen, ist jedes hundertste Jahr kein Schaltjahr, jedes vierhundertste aber doch ein Schaltjahr. 2000 ist demzufolge ein Schaltjahr, 2100 nicht.

Es besteht die Gefahr, daß findige Programmierer diese zusätzlichen Regeln nur halb beherzigt haben, so daß ihre Software den 29. Februar 2000 nicht kennt. Bislang ist nur eine Handvoll Bugs in der Schaltjahresberechnung bekannt. Der Benutzer-Manager in vielen Windows-NT-Versionen weigert sich, Accounts am 29. Februar 2000 enden zu lassen (siehe c't 1/99, S. 70). Das Bundesamt für Sicherheit in der Informationstechnik (BSI) berichtet, daß manche Funkuhren den 29. Februar 2000 überspringen [7]. Hier versagt wohl die Logik der zusätzlich eingebauten Quarzuhren.

Im Leben aktueller Soft- oder Hardware ist das Jahr 2000 das erste Schaltjahr, ein Problem für sich. Wenn die Entwickler aber überhaupt an Schaltjahre gedacht haben, sollte der 29. Februar 2000 keine Schwierigkeit sein. Denn dieser Tag folgt trotz aller Ausnahmeregeln dem simplen Vier-Jahres-Turnus.

Sieben Siegel

Unzählige Web-Seiten verbreiten tagesaktuelle Gerüchte über einen Weltuntergang in den Morgenstunden des 1. Januar 2000; die Newsgroup comp.software.year-2000 versammelt alle Kassandren des Globus. Wie vor jedem Jahrhundertwechsel sammeln sich die Mahner mit religiösem Eifer.

Soziologen sehen die Gefahr, daß das Jahr-2000-Problem über die Maßen aufgebauscht wird [8]. Schlechte Nachrichten verkaufen sich besser als gute, da drückt mancher Redakteur schon mal ein Auge zu und überprüft das frisch aus dem Internet gesaugte Gerücht nicht. Winzigste Macken gelangen auf die Titelseiten. Bootet man den Rechner Silvester wenige Sekunden vor Mitternacht, stellt Windows 98 manchmal das Jahr falsch ein - anscheinend eine Katastrophe, die gleichrangig ist mit einem Erdbeben in Mittelasien, das 1000 Menschenleben fordert.

Daß EDV-Berater und Buchautoren das Jahr 2000 so hoch wie möglich hängen, kann man ihnen kaum verdenken. Firmen könnten versucht sein, Modernisierungen als Jahr-2000-Reparaturen zu deklarieren, um steuersparend den Bilanzposten `außerplanmäßige Abschreibungen´ zu erhöhen.

Kontraproduktiv wirkt die notorische Beruhigungslitanei vieler deutscher Behörden und Firmen. Zwar wird oft auf Tests und Simulationen verwiesen; Einzelheiten darüber erfährt man aber meist nicht. Mißtrauische Gemüter könnten daraus lesen, daß die Tests entweder noch nicht begonnen haben oder aber daß sie bereits erschreckende Ergebnisse zeigen.

Wahrscheinlich ist weder das eine noch das andere der Fall. Die Zuständigen müssen lernen, daß man Vertrauen nur durch Offenheit schafft. Ein Gesetz wie der `Year 2000 Information and Readiness Disclosure Act´ der USA könnte helfen, die Zungen der Zuständigen zu lösen [9]. In den USA kann man nun sein Wissen über Jahr-2000-Fähigkeiten eigener oder fremder Hard- und Software verbreiten, ohne sich Schadensersatzforderungen auszusetzen.

Hochgeschätzt

Das Jahr 2000 resultiert in einer Folge von Nadelstichen, von denen niemand weiß, ob sie nicht in ihrer Summe vielleicht auch Leib und Leben von Menschen gefährden. Bislang konnten wir aber keine der diversen Meldungen verifizieren, in der das behauptet wird. Beunruhigend ist aber, wie langsam das Problem in Deutschland angegangen wird. Die Experimente der hannoverschen Stadtwerke zeigen, daß ohne große Tests die Lichter ausgehen könnten.

Am heimischen PC droht selten Ungemach, noch seltener an Videorecorder und Fax. Anders die Lage in Firmen und Verwaltungen: Wer an kritischen Stellen Software einsetzt, die ohne aufwendige Qualitätskontrollen geschrieben wurde, sitzt auf einer Zeitbombe, die spätestens am 1. Januar 2000 platzt - so unser Eindruck nach Gesprächen mit diversen Programmierern. Alle erinnerten sich an krumme Datumsberechnungen, die noch in ihrer Software lauern.

Gefahr droht von selbstprogrammierten Makros und Datenbanken ebenso wie von Spezialsoftware, die über die Jahre gewachsen ist - sei es das Datenaustauschprogramm einer internationalen Bank, das Verwaltungssystem eines mittelständischen Betriebs oder die Software für einen vollautomatischen Motorenprüfstand in der Autoindustrie. Wer Software oder Steuerungssysteme dieser Art einsetzt, muß sie dringend reparieren oder ersetzen.

Vielleicht ist es jetzt schon zu spät: Nur wenige Softwareprojekte werden erfolgreich abgeschlossen; eine vorgegebene Frist (unabänderliche zwölf Monate) hält kaum ein Projekt ein. Firmen könnten in die Pleite steuern, weil ihre Projekte scheitern oder weil die Kosten explodieren. Ein selbständiger Programmierer, der lieber ungenannt bleiben will, zu c't: `Das Jahr 2000 ist für mich ein warmer Regen, ähnlich wie die Umstellung der Postleitzahlen.´

Manche Analytiker trauen sich, in Zahlen anzugeben, wieviel Firmen das Jahr 2000 Kopf und Kragen kosten wird, weil Fertigungsbänder stillstehen oder Buchungssysteme versagen. Aber schon die Vorhersage, was ein Softwareprojekt kosten wird oder wann und ob es abgeschlossen wird, gerät zur wilden Spekulation. [10] Ins Blaue zu schätzen, wieviel gravierende Jahr-2000-Fehler auftreten werden, ohne daß es jemals zuvor ein Ereignis wie das Jahr 2000 gegeben hat, ist üble Kaffeesatzleserei.

Solarplexus

Besonders unsicher sind die Vorhersagen zu Energieversorgung, Telefon und Flugverkehr; solche vernetzten Systeme könnten einerseits besonders stabil sein, weil sich immer ein Umweg oder ein Ersatz findet. Andererseits legt schon mancher kleine Fehler einen Großteil des Netzes lahm. Selbst das als atombombensicher konzipierte Internet wurde im Juli 1997 zu großen Teilen niedergestreckt - durch einen Bedienungsfehler.

Wie sich so komplexe Systeme verhalten, läßt sich schwer prognostizieren, und Tests `im Großen´ sind undenkbar. Wer wollte etwa die Uhren aller Internet-Server und -Netzknoten testweise auf 2000 und dann wieder auf 1999 stellen?

Angst und Bange kann einem angesichts der russischen und amerikanischen Frühwarnsysteme werden. Die komplexe Technik ist in apokalyptischer Weise gekoppelt mit der Strategie `launch on warning´ (Start bei Warnung): Der Gegenschlag soll erfolgen, während die Raketen des Angreifers noch auf ihr Ziel zufliegen [11]. Die Präsidenten der USA und Rußlands müssen im Fall der Fälle binnen weniger Minuten eine Entscheidung treffen - auf Basis von per Computer ausgewerteten Radar- und Satellitenmessungen.

Roter Knopf

Im September 1998 haben Clinton und Jelzin vereinbart, die Meldungen der Frühwarnsysteme auszutauschen, um einen versehentlichen Atomschlag zu verhindern. Das Drehbuch für den nächsten Hollywood-Schocker sieht damit so aus: Am 1. Januar 2000, 00:15 h Ortszeit Moskau, melden die russischen Systeme, daß in elf Minuten Trident-Raketen in Moskau, Petersburg und Wladiwostok einschlagen. Der Wachhabende vom Dienst drängt sich durch die Silvesterfeier im Kreml. Er gestikuliert vor Jelzin mit dem Papierfetzen aus dem Fernschreiber. In Zeitlupe zersplittert das Glas Krimskoye des Präsidenten auf dem Marmorboden. Er läuft durch endlose Flure in sein Arbeitszimmer und greift zum schwarzen Koffer mit den Freischaltcodes. Den Koffer auf dem Schoß, nimmt er mit zitternden Fingern den roten Hörer von der Gabel. Ein Blick zur Uhr: noch drei Minuten. Spielen vielleicht nur die Rechner verrückt? Aus dem Hörer dröhnt Totenstille - Satellitenpanne ...

Literatur

[1] Peter Siering, C(r)ash 2000, Jahr 2000: das Geschäft mit der Angst, c't 14/97, S. 102

[2] Ed Yardeni, Year 2000 Recession?, http://www.webcom.com/~yardeni/y2kbook.html

[3] Food and Drug Administration, http://www.fda.gov/cdrh/yr2000/y2kintro.html

[4] Nuclear Regulatory Commission, http://www.nrc.gov/

[5] Jon Wessler u. a., Cobol unleashed, The comprehensive solution, SAMS, 1998

[6] Defense Logistics Agency´s Year 2000 Programm, http://www.stsc.hill.af.mil/crosstalk/1998/jan/dlay2k.html

[7] Bundesamt für Sicherheit in der Informationstechnik, Das Jahr-2000-Problem in der Bürokommunikation, http://www.bsi.bund.de/aufgaben/projekte/2000/jahr2000.htm

[8] http://www.heise.de/tp/deutsch/inhalt/co/2505/1.html

[9] Year 2000 Information and Readiness Disclosure Act, http://www.y2k.gov/java/y2kinfo.html

[10] Jörn Loviscach, Absturzgefahr, Die Bug-Story, c't 19/98, S. 156

[11] Michael Kraig, The Bug in the Bomb, http://www.basicint.org/y2krept.htm

---

Rechtsfragen zum Jahr 2000

Dr. Michael Bartsch

Angesichts der drohenden - und teilweise schon auftretenden - Pannen stehen Computeranwender vor der Frage, wer die Kosten für die Fehlerbehebung tragen muß und wer für Schäden aufzukommen hat. Die Rechtslage läßt sich nur schwer mit Pauschalantworten klären; deshalb führen wir hier einige wichtige Beispiele an. Weitergehende Informationen und aktuelle Meldungen finden sich im Internet unter:

http://www.bartsch-partner.de/aktuelles/

http://www.jahr-2000.de/studien.htm?studie=4

http://www.jahr2000.dgri.de/

Ich habe 1990 Software gekauft, die ab dem 1. Januar 2000 nicht mehr laufen wird. Was kann ich tun?

Es spricht einiges dafür, daß Software 1990 noch nicht 2000-fest sein mußte. Also lag bei der damaligen Lieferung kein Mangel vor, so daß keine Gewährleistungsansprüche bestehen. Auch bei eigens für den Kunden entwickelter Software wird 1990 (außer in Sonderfällen) kein Mangel vorgelegen haben. Je nach Konstellation kann das Softwarehaus aber verpflichtet sein, den Nutzer auf gravierende Fehler der Software hinzuweisen, damit er rechtzeitig umsteigen kann.

Ich habe Software gemietet, die ab dem 1. Januar 2000 nicht mehr laufen wird. Was kann ich tun?

Der Vermieter muß die Software während der Vertragsdauer mangelfrei halten. Spätestens heute ist fehlende 2000-Festigkeit ein Mangel. Also muß der Vermieter auf seine Kosten nachbessern, und zwar so früh, daß der Mieter bei einem eventuellen Scheitern der Nachbesserung noch Umstiegsmöglichkeiten hat. Problem: Der Vermieter kann den Mietvertrag vielleicht noch rechtzeitig kündigen.

Was muß ich heute in Verträge mit Softwarefirmen oder EDV-Beratern hineinschreiben?

Am besten: `Das Softwarehaus garantiert, daß die Software 2000-fest ist. Ansprüche hieraus verjähren frühestens am 31. Dezember 2001.´ Die Definition der 2000-Festigkeit und weitere Vorschläge zur Vertragsgestaltung kann man aus http://www.bsi.bund.de/aufgaben/projekte/2000/83.htm entnehmen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stellt dort zum Beispiel eine Übersetzung der Definition des British Standards Institute (ebenfalls BSI) bereit.

In Verträge mit Beratern muß man nicht unbedingt Sonderregeln aufnehmen. Berater haben seit langer Zeit dafür Sorge zu tragen, daß ihre Kunden 2000-feste Produkte kaufen und installieren. Berater haften 30 Jahre auch für leichtes Verschulden; die Haftungsbegrenzungsklauseln in Beraterverträgen sind meist unwirksam.

Der Hersteller meiner Software sagt, er weiß nicht, ob das Programm im Jahr 2000 noch läuft. Kann ich ihn zur Auskunft zwingen?

Das ist leider unklar. Fachjuristen, die sich am 4. Dezember 1998 in Karlsruhe zu einem Diskussionsforum der Deutschen Gesellschaft für Recht und Informatik (DGRI) getroffen haben, vertraten überwiegend die Meinung, daß es (außer bei bedeutungsloser Software) einen solchen Auskunftsanspruch gibt, und zwar aus vertraglicher Nachsorge. Ob die Pflicht besteht, muß man anhand der konkreten Gegebenheiten prüfen (Schäden durch verspätete Umrüstung, betriebliche Bedeutung der Software, Enge der Lieferantenbeziehung usw.).

Der Hersteller sagt, ich solle gefälligst auf die neue, 2000-feste, aber teurere Version umsteigen. Muß er mich kostenlos beliefern?

Wenn der Käufer für die alte Software noch Gewährleistungsansprüche hat (was in einigen Konstellationen noch lange nach Ablauf von sechs Monaten ab der Lieferung der Fall sein kann), dann wird das Softwarehaus die neue Version liefern müssen, aber nur gegen angemessenen Aufpreis, typischerweise die Kaufpreisdifferenz. Wenn keine Gewährleistungsansprüche mehr bestehen, ist der Verkäufer zu nichts verpflichtet. Leider kommt es auch hier auf den konkreten Sachverhalt an.

Und wenn ich mit dem Softwarehaus einen Pflegevertrag geschlossen habe?

Dann sieht alles anders aus. Nach den meisten Pflegeverträgen muß das Softwarehaus Fehler beseitigen oder zumindest in angemessenen Abständen eine neue (natürlich fehlerfreie, also auch 2000-feste) Programmversion liefern. Andernfalls kann es durch eine Mahnung in Verzug gesetzt werden, haftet aus Verzug auf Schadensersatz und riskiert die fristlose Kündigung des Pflegevertrages mit weiteren Schadensersatzfolgen. Dann kann es teuer werden für das Softwarehaus.

Anders aber, wenn der Pflegevertrag lediglich eine Art Seelsorge ist, also nur Hotline bietet und Rabatt auf eventuelle neue Programmversionen. Dann wird es dem Softwarehaus freistehen, überhaupt solche neuen Versionen auf den Markt zu bringen.

Wer muß zahlen, wenn Software oder Hardware einen Schaden verursacht?

Schutz besteht nur gegen Personen- und Sachschäden und die daraus entstehenden Folgeschäden, aber nicht unmittelbar gegen Vermögensschäden.

Personenschaden: Eine Ampelsteuerung schaltet am 31. Dezember 1999, 23.59 Uhr alle Fahrtrichtungen auf Grün. Zwei Fahrer werden bei einem daraus resultierenden Unfall verletzt. Wer für die Ampelsteuerung verantwortlich ist (die Stadtwerke, der leitende Techniker, das Softwarehaus), ist schadensersatzpflichtig.

Sachschaden: Am 1. Januar 2000 setzt eine Kühlpumpe aus, weil ihre Steuerung die falsche Information liefert, die letzte Wartung liege schon hundert Jahre zurück. Durch den Ausfall entsteht Sachschaden an anderen Maschinen. Erstattungspflichtig ist, wer für die fehlerhafte Steuerung verantwortlich ist. Auch der Hersteller des `Embedded System´ und der Ingenieur, der damals für die Konstruktion verantwortlich war, können schadensersatzpflichtig sein.

Auch Eingriffe in gespeicherte Daten sind Sachschäden. Werden also Daten fehlerhaft gelöscht oder geändert oder ist der Zugriff auf die Daten nicht mehr möglich, besteht Schadensersatzpflicht nach den Prinzipien der Produkthaftung.

Vermögensschaden: Die Software zur Finanzbuchhaltung weigert sich, Rechnungen mit Jahresangabe 2000 zu drucken; zwei Monate kann das Unternehmen keine Rechnungen stellen. Die Gelder gehen entsprechend verspätet ein. Das Unternehmen erleidet einen hohen Zinsschaden.

Was kann ich sonst tun?

Versuchen Sie, auf den Hersteller oder den Lieferanten zuzugehen. Arbeiten Sie an der technischen Problemlösung mit; stellen Sie keine technisch oder wirtschaftlich unerfüllbare Forderung. Je schwieriger die Lage ist, desto wichtiger ist es, auf Kooperation zu setzen statt auf Konfrontation.

Rechtsanwalt Dr. Michael Bartsch ist Lehrbeauftragter der Universität Karlsruhe.

---

Skurriles Jahr 2000

Im Herbst 1999 wollen Warner Bros. einen Film mit Chris O´Donnell als Jahr-2000-Programmierer in die US-Kinos bringen. Ob Stu Zichermans Drehbuch auf der Vorlage in c't 14/98, S. 3 beruht, konnten wir noch nicht in Erfahrung bringen.

High Valley Cyber Development in Monte Vista, Colorado, offeriert den Jahr-2000-festen Firmensitz. Stromversorgung über Solarzellen und eigene Generatoren sowie Satellitentelefon sollen den ungestörten Betrieb sicherstellen (http://www.hvcd.com).

Ed Yardeni von Deutsche Bank Securities, New York, empfiehlt allen Bankkunden, die Angst um ihre Einlagen haben, kein Bargeld abzuheben, sondern Zweit- und Drittkonten bei anderen Instituten anzulegen - und die Papierbelege über den Kontostand aufzubewahren.

Alle wilden Gerüchte zum Thema, sauber sortiert nach Kategorien von Geschäft bis Versorger, versammelt die Web-Seite der Computer Professionals for Social Responsibility. (http://www.cpsr.org/program/y2k/rumors/)

Ein Gericht in Santa Clara, USA, hat eine Klage gegen Intuit abgewiesen. Der Kläger wollte sich nicht zu einem Update von Intuits Kontoführungssoftware Quicken zwingen lassen, um auch nach dem 31. Dezember 1999 Buchungen per Modem an die Bank übermitteln zu können. Das Gericht erklärte, daß noch kein Schaden entstanden sei. ()