"Digital Cassandra", "Millennium Moaner" und "Doomssayer" sind einige der Anreden, die der Berater und Autor Peter de Jager des oefteren hoert. Er hatte bereits am 6. September 1993 in einem Artikel der CW-Schwesterpublikation "Computerworld" davor gewarnt, dass eine Gefahr auf alle DV-Anwender zukommt: Programme mit zweistelligen Jahreszahlen werden die ab dem 1. Januar 2000 im Datumsfeld erscheinenden zwei Nullen nicht als 2000, sondern als 1900 interpretieren.

Denn auf 99 wird 00 folgen, eine Zahl also, die kleiner ist als die erste. Die Zeit geht aus Sicht der Programme nicht voran, sondern macht einen Schritt zurueck, was fatale Konsequenzen hat. Sort-Routinen stellen 00 vor 99. Berechnungen von Alter, Schuld- und Guthabenzinsen werden beispielsweise absurde Ergebnisse liefern.

Das Problem 2000 beginnt nicht am 1. Januar jenes Jahres. Alle zukunftsgerichteten Berechnungen kommen vorher bei dem kritischen Datum an. Die ueblichen, auf drei Jahre angelegten Kalkulationen sind ab 1997 betroffen. Die Gartner Group erwartet, dass schon in diesem Jahr 20 Prozent aller Applikationen Schwierigkeiten machen werden.

Die Ursache des Problems ist historischer Art. Als die Datenverarbeitung in den 60er Jahren schnelle Verbreitung fand, waren Haupt- und Massenspeicher suendhaft teuer.

Was einst Spitzenleistung der Programmierkunst war

Jede Moeglichkeit, Bytes zu sparen, wurde genutzt. Und eine davon bestand darin, sich statt der Schreibweise 19xx mit xx zu begnuegen. Das hatte den angenehmen Nebeneffekt, dass sich die Anwender bei einer so haeufigen Eingabe wie der Jahreszahl zwei Tasten sparen konnten.

Kein DV-Experte hielt das fuer ein Problem, denn niemand erwartete damals, dass diese fruehen Programme 30 Jahre und laenger in Betrieb sein koennten. Ihre vorzeitige Ausmusterung galt als so selbstverstaendlich, dass selbst Programmiergrundlagen wie die Sprache Cobol oder die IBM-Datenbank IMS schon per se Jahresangaben auf zwei Stellen nahelegten.

Die Bescheidenheit damaliger Programmierartisten hat jetzt ihre Konsequenzen: In Anwendungen, Datenbank-Files, Job Control Languages etc. finden sich zweistellige Jahreszahlen. Und nicht nur da: Die Abkuerzung ist auch im PC-BIOS, in Netzwerken, sogar in der Peripheriehardware enthalten.

Dies macht Schaetzungen, wie gross das Problem ueberhaupt sein koennte, ueberaus schwierig. Alle bekannten Berechnungen beschraenken sich auf den Software-Aspekt. Und die Analysten neigen dazu, ihre Hochrechnungen ueber den zu erwartenden Aufwand nach oben zu korrigieren.

IBM schaetzt derzeit, dass die Kosten fuer Jahr-2000-Projekte etwa den weltweiten IT-Ausgaben des Jahres 1993 entsprechen werden: 386 Milliarden Dollar, davon 127 Milliarden allein in Europa, waren das. Die Unternehmensberatung Gartner Group setzt die weltweiten Kosten fuer die Umstellungen auf vierstellige Jahreszahlen mit 300 bis 600 Milliarden Dollar an.

Helmut Wolf, Leiter des IBM-Projekts "Datum 2000", meint: "Es gibt weltweit zirka 120 Milliarden Lines of Code (LoC) aus Cobol-, Assembler-, PL/1- und RPG-Altanwendungen, die untersucht werden muessen. Fuer Deutschland schaetzen wir sieben Milliarden LoC."

Nach den ersten Analysen geht Wolf davon aus, dass "80 bis 90 Prozent der Programme betroffen" sind. Er berichtet von Kunden, die zwischen zehn und 45 Millionen LoC zu bewaeltigen haben, "es gibt aber noch groessere Volumen".

Die Union Pacific Corp. glaubt, dass 82 Prozent ihrer Programme das Datumsproblem haben, hochgerechnete Kosten der Umstellung: 25 Millionen Dollar. Die Northern Telecom Inc. entdeckte zweistellige Jahreszahlen in allen bisher untersuchten Systemen. Texaco ist etwas besser dran: 65 Prozent der Software gelten als kritisch. Shell steht vor dem Problem, weltweit ueber 70000 Programme mit weit mehr als 100 Millionen Lines of Code ueberpruefen zu muessen.

Ein halbes bis ganzes DV-Jahresbudget noetig

Dies hat finanzielle und personelle Konsequenzen. Fuer die Sanierung reiner Cobol-Anwendungen in einer einheitlichen Systemumgebung kalkuliert IBM - diesmal in der Rolle eines der weltweit am schlimmsten betroffenen Anwender - Kosten von 60 Pfennig pro LoC. In heterogenen Umgebungen waere eher eine Mark fuer jede Codezeile anzusetzen. Die Folge ist, dass je nach den Umstaenden ein halbes bis ein ganzes DV-Jahresbudget pro Unternehmen fuer die Umstellung auf vierstellige Jahreszahlen noetig sein wird.

Nicht weniger haarstraeubend ist der Personalbedarf. Projektleiter Wolf geht davon aus, dass fuer die Untersuchung von sieben Milliarden Programmierzeilen in Deutschland 35000 Personaljahre erforderlich waeren. Das ergibt bei nicht ganz vier Jahren verbleibender Zeit einen Bedarf von 9000 Programmierern.

Die Canadian Imperial Bank of Commerce (CIBC) in Toronto hat begonnen, saemtliche ihrer mehr als 200 wichtigsten Applikationen mit insgesamt ueber 50 Millionen LoC zu untersuchen und zu bereinigen. Trotz massiven Einsatzes von Tools befuerchtet das Institut Personalengpaesse.

John Burns, als CIBC-Vice-President Projects auch zustaendig fuer das Vorhaben "Year 2000", warnt deshalb: "1997 bis 1998 werden die meisten DV-Verantwortlichen aufwachen und feststellen, dass sie gut und gerne 30 Prozent mehr Personal brauchen, um in zwei Jahren das Projekt 2000 ueber die Buehne zu kriegen. Wenn alle Anwender ihre DV-Staebe nur um zehn bis 15 Prozent ausbauen muessten, wird das Angebot nicht mit der Nachfrage Schritt halten koennen."

Folglich ist schon jetzt abzusehen, dass die Kosten in die Hoehe schnellen werden, je naeher das ominoese Datum heranrueckt. So erwartet die Meta Group jaehrliche Kostensteigerungen von 30 Prozent. Die DV-Industrie und die Beratungsunternehmen richten sich auf ein todsicheres Geschaeft ein, weit besser als das mit der Postleitzahlen-Umstellung.

Arnd Paehlig, Mitglied der Task Force "Change of Century" bei CSC Ploenzke, schrieb in einem Beitrag fuer die Dezemberausgabe der Mitarbeiterzeitschrift "News": "Ich will, dass wir aus der 2 vorne dran ein Geschaeft machen."

DV-Anbieter gruenden eigene Competence Centers, sogar ganze Firmen entstehen mit dem ausschliesslichen Ziel der Datumsumstellung. In New York gibt es ein neues Beratungsunternehmen mit dem Namen 2000AD Inc. Am selben Ort erscheint ein spezialisierter Newsletter - der bezeichnende Titel der Publika-tion: "Tick, Tick, Tick".

Nicht nur mit Tools und Beratungsleistungen laesst sich Geld verdienen. Millionen PCs sind zu ersetzen, weil ihr BIOS nur ein zweistelliges Datum kennt. Timer in jedweder Hardware muessen ersetzt werden. Selbst in den Datenarchiven droht Chaos: Baender waren frueher teuer und wurden "bis Oberkante Unterlippe" vollgeschrieben; zwei Byte mehr pro Datumsfeld, und sie laufen ueber. Ihre Ueberarbeitung verlangt stapelweise neue Baender - und eine neue Organisation ihrer Archivierung. Auch CDs muessen teilweise neu gepresst werden.

Die Kosten fuer die Umstellung der DV sind kaum kalkulierbar. Allerdings werden sie hoch sein - ein Umstand, der viele DV-Leiter vor der Aufgabe zurueckschrekken laesst. Wie sollen sie mit derlei vagen Berechnungen die Geschaeftsleitung um mindestens einen halben zusaetzlichen DV-Jahresetat angehen? Und das zu einer Zeit, in der jeder zweite Manager die Berechtigung der enormen DV-Kosten in Frage stellt.

Der anfallende Aufwand ist - und das macht die Sache so schwer erklaerbar - vollkommen unproduktiv. Mit den Ausgaben wird die hauseigene DV keinen Deut besser dazu beitragen koennen, dass ein Unternehmen neue Produkte entwickeln, effizienter arbeiten und Alleinstellungsmerkmale am Markt erringen kann. Aber ohne diese Investitionen koennte es das Unternehmen bald ueberhaupt nicht mehr am Markt geben.

Dabei ist es trotz aller Kosten noch nicht einmal sicher, dass die Umstellungsbemuehungen auch 100prozentig zum Erfolg fuehren. "Unsere Untersuchungen haben ergeben, dass man ohne die geeigneten Werkzeuge bis zu 20 Prozent der Felder nicht findet, die angegangen werden muessen", erklaert IBM-Projektleiter Wolf.

Er hat dazu den durchschnittlichen Bestand eines Grosssystemanwenders mit 15000 Programmen und zirka 150000 Datumsfeldern untersucht. Wenn 70 Prozent der Datumsfelder im Status "current" sind, wuerden 105000 Felder am 1. Januar 2000 einen Fehler erzeugen. 20 Prozent Restfehlerquote wuerden bedeuten, dass 21000 fehlerhafte Felder nicht identifiziert sind.

Der Programmiererspass mit den Vornamen

Dabei hueten sich die Anbieter vor dem Versprechen, mit ihren Tools ein System 100prozentig "clean" zu bekommen. Schon die Suche nach den Datumsfeldern ist ein anspruchsvolles Unterfangen. Keineswegs haben diese naemlich durchweg so eindeutige Namen wie "ttmmjj", "mmttyy" oder "Year". Vielmehr haben sich Generationen von Programmierer einen Spass daraus gemacht, die Namen ihrer Angehoerigen und Lebensabschnittsgefaehrtinnen zu verewigen. Dokumentiert sind solche Dinge natuerlich nur in den seltensten Faellen.

Zu einer weiteren Verkomplizierung traegt die Tatsache bei, dass es sich bei Datumsfeldern nicht ausschliesslich um einfache passive Eintraege handelt. Haeufig stoesst das Datumsfeld andere Operationen an. Nach einer IBM-Untersuchung handelt es sich bei durchschnittlich einem Drittel aller entsprechenden Felder um Datumsnutzung mit Weiterverarbeitung.

Im Lernvideo "Millennium: A Billion-Dollar Software Crisis" von Computer Channel fuehrt Howard Rubin von Cap Gemini America ein Tool seines Hauses vor. Es erkennt fast 50 verschiedene eindeutige Namen fuer Datumsfelder nach obiger Art. Ausserdem sucht es nach allen "merkwuerdigen" Namen in einem Programm. Ob es sich aber beispielsweise bei "Tracy" um ein Datumsfeld handelt oder um den Trigger einer verballhornten Suchroutine, muss der Anwender im Zweifelsfall "zu Fuss" herausfinden.

Dabei ist, wie auch Rubin feststellt, die Umstellung nicht so sehr ein technisches Problem. Vielmehr bereitet die grosse Zahl der Umstellungsdetails Schwierigkeiten, die sich ohne sehr praezises Projekt-Management nicht loesen lassen. Rubin empfiehlt ein Vorgehen in fuenf Schritten: Zunaechst sei das Ausmass des Problems einigermassen genau zu analysieren. Als naechstes folgt die Festlegung der Strategie: Welche Software ist unter Kostenaspekten besser zu ueberarbeiten oder durch neue Pakete zu ersetzen? Mit welchen Kosten ist zu rechnen? Es folgt offline die Ueberarbeitung der Daten und Programme, ihr Test und schliesslich ihre Implementierung.

Rubin, der das Problem staendig als "doomsday" (Juengster Tag) bezeichnet, uebersieht jedoch ein Hoellenfahrtskommando: Es ist nahezu unmoeglich, ein ueberarbeitetes Programm hinreichend zu testen. Denn nicht nur die Software, auch Hardware und Netze sind betroffen. Eine sichere Simulation der neuen Software wuerde voraussetzen, die gesamte DV-Umgebung eines Unternehmen eins zu eins nachzubilden. Das laesst sich aus Kostengruenden noch nicht einmal mit kleineren DV-Umgebungen realisieren.

Wer es trotzdem schafft, sein DV-System "clean" zu bekommen, kann sich noch immer nicht vollstaendig auf der sicheren Seite waehnen. Jede DV hat Schnittstellen nach aussen. Es wird sich auf Jahre hinaus nicht ausschliessen lassen, dass es beim Datenaustausch mit Geschaeftspartnern zu Konflikten mit den Jahreszahlen kommt. Alle Schnittstellen sind also besonders zu sichern.

Der gewaltige Aufwand fuer die Umstellung wird noch einen weiteren unangenehmen Nebeneffekt haben: Vielen Firmen duerften noch weniger Mittel als bisher fuer andere IT-Aufgaben zur Verfuegung stehen. Ein IBM-Papier sagt sogar dramatische Entwicklungen voraus: "Einige Unternehmen werden nicht in der Lage sein, die Kosten zu tragen." Das hat zur Folge, dass die Anwender an allen anderen DV- Kostenstellen sparen muessen.

Dies hat Konsequenzen fuer die gesamte DV-Industrie. Wenn die Anwender ihre Investitionen vorrangig auf einen Punkt konzentrieren, werden die Anbieter Um-satzeinbrueche erleben. Es bleibt der DV-Industrie also gar nichts anderes uebrig, als sich als Loesungsanbieter fuer das "Problem 2000" zu profilieren.

Die Kosten in anderen Projekten verstecken

Eine sowohl fuer die Anwender als auch die Hersteller besonders clevere Variante koennte darin bestehen, die Kosten zu verstecken. Das laesst sich zum Beispiel dadurch realisieren, dass man einen Teil der Umstellung im Rahmen routinemaessiger Softwarewartung oder einer Neugestaltung der Benutzeroberflaechen durchfuehrt. Noch bessere Vertuschungsmoeglichkeiten bietet der Uebergang zu Client-Server- Computing oder zu objektorientierter Programmierung.

Doch dafuer, den Aufwand und die Kosten der Umstellung zum Anlass fuer eine voellige Umorientierung der bisherigen DV-Strategie eines Unternehmens zu nehmen, ist die Zeit viel zu knapp. Alle Kenner der Materie warnen, dass die vier verbleibenden Jahre fuer Analyse, Methodenauswahl, Behebung, Tests und Implementierung kein Zoegern mehr zulassen.

Die Anwender muessen aktiv werden. Je spaeter, desto teurer und unsicherer werden die Massnahmen. Der 1. Januar 2000 faellt auf einen Samstag. An dem Wochenende werden wohl alle DV-Staebe komplett in ihren Bueros sein.

Kurz & buendig

Das Problem mit den Nullen in der zweistelligen Darstellung des Jahres 2000 beschraenkt sich nicht auf den 1. Januar jenes Jahres oder auf Cobol-Programme. Die Konfusion, die ausbrechen wird, weil 00 kleiner ist als 99, tritt frueher ein und hat ihre Ursachen in allen moeglichen Programmen, Datenbestaenden, selbst Netzwerken und Hardware. Das Jahr-2000-Problem ist nicht so sehr technischer, sondern organisatorischer Art. Es ist nicht voraussehbar, wo Datumsfelder Schwierigkeiten bereiten koennten. Deshalb lassen sich weder die finanziellen noch die personellen Aufwaende fuer eine Loesung kalkulieren. Die Datumsumstellung wird das groesste und gleichzeitig an Ueberraschungen reichste Softwareprojekt in der Geschichte der DV-Industrie. Und es ist das erste Projekt, das eine unverschiebbare Deadline hat: Am 1. Januar 2000 muessen alle Gefahren endgueltig aus dem Wege geraeumt sein.