Im Hauptbahnhof Zuerich kuendete eine seltsame Uhr am 15. Dezember 1995 das Ende des Jahrtausends an: "Noch 1477 Tage bis zum Jahr 2000." Inzwischen sind es schon etliche weniger. Vorfreude? Oder dumpfe Aengste wie vor tausend Jahren wegen des damals erwarteten Weltuntergangs? Den wird es nicht geben. Vielerorts aber droht ein Fiasko, wenn die Informationstechnik, der sensibelste Teil von Unternehmen und Verwaltungen, ausfaellt.
Die Warnungen und Aktivitaeten haeufen sich: Vom 18. bis 21. Maerz 1996 wird in Washington eine Konferenz "Year 2000 Solutions" stattfinden. IBM rief am 30. Oktober 1995 uebers Internet zu einem Meeting "Year 2000". Doch schon am 3. September 1993 hatte Peter de Jaeger vor der ersten Sekunde des neuen Jahrtausends gewarnt. Der auf dieses Problemfeld spezialisierte kanadische Berater schrieb damals in einem "Computerworld"-Beitrag: "2000: Das ist eine Geschichte mit guten und schlechten Nachrichten. Die schlechten zuerst: Es gibt wenig gute." Dann zitiert er Tom Love, IBMs Vizepraesident der Object-Oriented Group fuer die gute: "Objektorientierung koennte das Problem meistern."
Die Folgen alter Programmierakrobatik sollten eigentlich heutigen IT-Managern heftiges Kopfzerbrechen bereiten. Doch scheint dem nicht so zu sein, wie Stimmen aus ihrem Kreis belegen. Wer denkt schon an alte Sort- oder an nur alle zwei Jahre laufende Reorganisations-Programme? Wer weiss noch von den Uraltklamotten, von denen moeglicherweise noch nicht einmal mehr die Sourcecodes aufzufinden sind?
Eine kleine Anregung zum Nachdenken gibt Reinhard Janning, deutscher Vertriebschef der Cobol-Company Micro Focus: "In einem kuerzlich abgehaltenen Seminar haben wir ausser bei einem Besucher kaum Interesse und noch weniger Aktivitaeten bezueglich des Datumswechsels 2000 feststellen koennen." Amdahls Marketing-Leiter Bernd Tillak berichtet leicht enttaeuscht von einer im letzten September abgehaltenen Bankentagung: "Es war schon sehr durchwachsen. Einige Teilnehmer schienen ueber die Thematik verdutzt, andere geschockt."
Es scheint, als wuerden die Anwender das Problem als nicht existent oder halb so wild ansehen. Wenn doch, dann wird - nach deutscher Manier - erst einmal eine Projektgruppe gebildet und ein Plan diskutiert. Bis es zu spaet ist. Manche Firmen haben ueber 2000 hinaus sogar noch eine Schonfrist von ein paar Jahren, bis ihre auf irgendeinen Tag zu Beginn unseres Jahrhunderts bezogene Datumsrechnung den Geist aufgibt.
Gelassen sieht Otto Tietze, Vorsitzender des Verbands der DEC- Benutzer, Decus, das Problem: "Die Grossanwender kennen diese Schwaeche, dafuer haben sie ihre Systemgruppen." Ausserdem moechte er die Frage insgesamt vorsichtig bewerten und meint: "Dass sie nun so virulent ist, dient der Sensibilisierung des Managements." In puncto Kostensituation wisse ohnehin niemand Genaues. Die vielfach zitierten Schaetzungen der grossen Marktforschungsinstitute und Unternehmensberatungen wirken auf den ersten Blick in der Tat wie Panikmache.
"Wer denkt, er habe Zeit, der irrt"
In einer Meldung von Elec-tronic Data Systems (EDS) im Decusnet heisst es allerdings: "Wer denkt, er habe Zeit, der irrt. Fuer ein grosses Unternehmen kann es schon jetzt zu spaet sein, wenn Aktivitaeten nicht bereits gestartet wurden." EDS wird noch deutlicher: "Je naeher wir 2000 kommen, um so groesser wird die dann ausbrechende Panik sein - und um so geringer folglich die Chance, das Problem systematisch in den Griff zu bekommen."
Hilfe zur Selbsthilfe geben in der Notiz etwa 25 Hinweise auf aenderungskritische Themenbereiche, vom einfachen Report bis hin zu Bildschirmmasken. Wohl dem, der in MVS- oder AS/400-Umgebungen, oder unter CICS mit Eibdate, das Systemdatum verwendet. Er hat - durch eine Jahrtausendkennung - Ruhe bis 3000.
"Bei uns hat es schon geknallt", erklaert lapidar Juergen Dinser von Arthur Andersen Consulting. Ueber das Datum 2000 hinausreichende Planungsrechnungen machten dem Berater Schwierigkeiten. Dahintergekommen war er mehr durch Zufall. Ihn aergerte, dass Kunden bei Musterrechnungen ein veraltetes Datum monierten. Deshalb verlegte er seine Beispiele bereits vor drei Jahren in die Zukunft. Kaum tauchte das Jahr 2000 auf, wurde das Dilemma offensichtlich.
"Die Probleme haengen jedoch vom System ab und sind von Fall zu Fall unterschiedlich zu werten", relativiert Dinser. Sein Hinweis gilt eigenentwickelten Schnittstellen zwischen Anwendungen. Sie sollten genau untersucht werden.
Klaus Krueger, Mathematiker bei einer Versicherung, ist im Arbeitskreis "Application Development" von Guide, der IBM- Grosssystemanwender-Vereinigung, engagiert. Er warnt in die andere Richtung: "Von Panikmache, wie zum Teil in der Presse zu lesen, ist auf jeden Fall abzuraten." Er sieht die Situation, auch im Unternehmen, nuechtern: "Aehnliche Vorhaben - etwa die Postleitzahlenumstellung - gingen praktisch reibungslos mit normaler Wartung ueber die Buehne."
Wozu also die Aufregung? Schliesslich gibt es noch mehr Aenderungen, zum Beispiel infolge von Gesetzen, die die Anwendungsunternehmen - und sei es mit Ueberstunden - immer noch fristgerecht abgeschlossen haben.
Bei der Recherche zu diesem Beitrag stellte sich heraus, dass Anwender die Problematik im allgemeinen kennen und zum Teil schon darauf reagieren. Dies geschieht ohne grosse Aufregung (noch) nicht in Form eigener Projekte, sondern beispielsweise als Nebenaufgabe bei ohnehin anfallenden Wartungsarbeiten.
Bei einigen Unternehmen, etwa Finanzverwaltungen oder dem ADAC in Muenchen, sind bereits Untersuchungen im Gange. Hermann Rangl, DV- Experte beim ADAC, meint: "Der Endbenutzer muss fuer das Thema sensibilisiert werden, da er die operativen Ablaeufe und damit das Auftreten von Datumsabhaengigkeiten besser kennt und beurteilen kann."
Rangl ist seit einiger Zeit dabei, eine Analyse fuer die Aufwandsschaetzung aufzubereiten. Doch fuer einen Ueberblick ueber die Kosten ist es noch zu frueh. Er will die Umstellung jedenfalls als ganz normales Projekt einordnen.
Auch die Finanzaemter lassen sich von der Thematik nicht ueberfahren. Wer dies heimlich hoffte, muss sich von Peter Handrock, Gruppenleiter Automation der Finanzverwaltung Nordrhein-Westfalen in Duesseldorf, eines Besseren belehren lassen: "Ja, wir kennen das Problem. Es trifft uns zum Beispiel bei Steuerfestsetzungen lange Zeit vorher." Tausende von Anwendungen werden derzeit analysiert: Den Aufwand kann auch er noch nicht benennen, nur "dass die Umstellung teuer wird".
Ein anderes Denken vertritt Roland Pfisterer. Er ist Geschaeftsfuehrer des Systemhauses sdh in Koeln, der fuer Informationstechnik im Hause Lekkerland zustaendigen Tochtergesellschaft des Lebensmittelgrosshaendlers. Damit am Tag X an Tankstellenshops niemand auf Schokolade oder Getraenke verzichten muss, waehlt er den Weg, alte selbsterstellte Software durch Standardpakete zu ersetzen. Pfisterer geht davon aus, dass sich damit das Problem erledigt: "Wir hoffen, zum Jahrtausendwechsel dann nur noch geringfuegige Altbestaende umstellen zu muessen."
Die Anwendervereinigungen, ob Safe von Siemens-Nixdorf oder Guide, laesst die aufregende letzte Sekunde des Jahrtausends ebenfalls kalt: kein Thema. Die Haltung von Krueger oder auch Handrock ist fast symptomatisch fuer die allgemeine Einstellung. Selbst im Bonner Bundesamt fuer Sicherheit in der Informationstechnik regt man sich wenig auf. Ein Mitarbeiter: "Dann muessen eben speicherresidente kleine Programme mit Korrekturen auf das Datumsfeld das Problem abfangen."
*Karl-Ferdinand Daemisch ist freier Fachjournalist in Loerrach.
"Fast alle unsere Dateien, die Statistikdaten fuer Jahre beziehungsweise Monate speichern, benutzen als Key eine zweistellige Jahreszahl ... Ich glaube, dass die Problematik ueberschaubar und kurzfristig loesbar ist, zumindest mache ich mir zur Zeit keine Sorgen deswegen, achte aber bei neuen Programmen darauf, dass es auch noch im naechsten Millenium funktioniert." Ein Anwender im Compuserve.
Kurz & buendig
Immer wieder berichten Anbieter von Loesungen fuer die Umstellung auf vierstellige Jahreszahlen von einer erstaunlichen Gelassenheit der Anwender. Etliche wuerden das Problem schlicht ignorieren, die meisten es zwar zur Kenntnis nehmen, aber als nicht so wichtig beiseite schieben. Die Recherche des Autors unter deutschen Anwendern hat in der Tat ergeben, dass das Problem 2000 die Anwender kaum beunruhigt.