Das Jahr-2000-Problem: Tagebuch, Archiv Woche 16

IBM ist die Mainframe-Firma überhaupt. Punkto Mainframes rangieren alle anderen Anbieter unter "ferner liefen". Und weil viele grosse und wichtige, aber nicht jahr-2000-fähige Programme auf Mainframes laufen, spielt es eine wichtige Rolle, was IBM punkto Jahr 2000 unternimmt.

Die IBM verschickt regelmässig an Entwickler die Zeitschrift IBM.d_m@il. Die aktuelle Ausgabe ist auch im Internet im öffentlichen Teil der IBM Developer Support Site unter http://www.developer.ibm.com/news/dmail/0298/index.html zugänglich. Sie ist im wesentlichen dem Jahr 2000 gewidmet.

Was ich da lesen kann, will mir nicht recht gefallen. Es beginnt bereits bei der Bezeichnung des Problems: Offenbar ist es offizielle Sprachregelung bei IBM, von der Year 2000 Challenge zu sprechen. Soso, "Herausforderung" nennt man das jetzt!

Zur Unterstützung der Entwickler bei Jahr-2000-Umstellungen hat IBM die Millennium Language Extensions erfunden und ihre Cobol-Compiler damit ausgestattet. Worum geht es da? Kurz gesagt um eine Unterstützung bei der Implementation von "Windowing". Wie ich am Montag ausgeführt habe, ist Windowing eine halbherzige und zudem fehleranfällige Lösung des Problems. Kein Wort hiervon bei IBM.

Im Bericht über die "Southern Californian Edison" ist die Rede von einem Program Understanding Tool, das bei der Umstellung von Programmen helfen könne. Ich kenne dieses Tool nicht, bin mir aber sicher, dass der Name nur ein Witz sein kann: Kein heute existierendes Programm ist in der Lage, ein anderes Programm zu "verstehen". Der Name weckt also höchstens falsche Hoffnungen.

Und dann zu guter Letzt die Liste der Useful Year 2000 Web Sites. Ausser der Site von de Jager, die man ja nicht gut weglassen kann ( http://www.year2000.com ) nur Sites von IBM, etwa 30 Stück. Als ob sonst nichts nützlich wäre. "Not Invented Here" in Reinkultur.

In meinen Augen eine recht schwache Vorstellung vom weltgrössten IT-Konzern. Ich glaube, von IBM hat die Welt leider keine allzu grosse Hilfe zu erwarten bei der Bewältigung der Jahr-2000-Problems.

Es ist fast nicht zu glauben, was gewisse Leute alles glauben. Im Internet sind z.B. unter http://www.execpc.com/vjentpr/holearth.html die Leute vertreten, die allen Ernstes glauben, die Erde sei hohl. Aber eine hohle Erde ist immer noch besser als das Folgende: Die Leute der "Flat Earth Society" nehmen an, die Erde sei flach - ist aus der Bibel abzuleiten (siehe Artikel unter http://www.talkorigins.org/faqs/flatearth.html ).

Da ist es nicht weiter verwunderlich, dass es Leute gibt, die glauben, das Jahr 2000 sei kein Problem, und zwar nicht nur Sonderlinge und Leute, die sowieso nicht so durchblicken.

Im Forbes-Magazin (das ja nicht irgendein Provinz-Blättchen ist) erschien kürzlich ein Artikel mit dem Titel "Y2K Fear Merchants" (zu finden unter http://www.forbes.com/tool/html/98/mar/0312/feat.htm ). Der Artikel beginnt wie folgt:

Who needs facts when you are peddling fear and panic. That seems to be the case with the hype that is portraying the Year 2000 computer bug as the biggest threat to civilization since Godzilla destroyed Tokyo.

Zentrale These, etwas vereinfacht dargestellt: Die Computerbranche verwende geschickt das Jahr-2000-Problem, um den Leuten Angst zu machen und dann auf verschiedenste Weise an dieser Angst zu verdienen. Dabei sei das Problem zwar echt, aber keinesfalls so gravierend, wie man uns weismachen will.

Ich muss Ihnen gestehen: Auch ich habe gelegentlich kurze schwache Momente, in denen ich mich frage, ob das Ganze nicht nur ein Riesen-Bluff ist. Der Drang, vor einem schwierigen Problem die Augen zu verschliessen, ist einfach da, wohl in jedem von uns, wenn auch unterschiedlich stark.

Und wissen Sie was? Ich glaube, die vertretene These mit dem Angst-Machen ist sogar in gewissen Fällen richtig. Wenn ich ein Beratungs-Unternehmen habe, das ein Jahr-2000-Seminar für Manager organisiert und dieses für 1000 Dollar pro Tag an den Mann bringen will, werde ich ja kaum behaupten, alles sei halb so wild, oder?

Nur: Wer jetzt hieraus schliesst, es werde nur übertrieben, und das Problem sei tatsächlich keines, liegt falsch.

Wenn in den folgenden Monaten das wahre Ausmass des Jahr-2000-Problems bekannt wird, nehmen wohl auch die Stimmen zu, die behaupten, alles sei nur Panikmache. Denn das Problem in seinen wahren Ausmassen wird kaum leichter zu glauben sein als das, was bereits bekannt ist.

Erliegen Sie nicht der Versuchung, diesen Stimmen zu glauben.

Wenn man spekuliert, was am 1.1.2000 alles Schlimmes passieren wird, ist man ziemlich angreifbar, denn man kann ja heute im Voraus kaum etwas beweisen. Wenn Skeptiker sagen, dass man nicht wirklich wissen kann, was passieren wird, haben sie im Grunde ja sogar recht. Wissen kann man es nicht.

Was man allerdings wissen kann, ist das, was bereits passiert ist. Aus diesem Grunde möchte ich Ihnen heute eine äusserst interessante und ergiebige Informations-Quelle vorstellen, die zu Unrecht kaum bekannt ist. Es handelt sich um The Risks Digest.

Unter diesem Titel tragen seit mehr als 10 Jahren Leute unter der Führung von Peter G. Neumann Vorfälle rund um Computer zusammen. Im WWW findet man dieses Forum unter http://catless.ncl.ac.uk/Risks .

Und was so alles bereits passiert ist (und damit auch durch Skeptiker nicht zu leugnen), lässt für das Jahr 2000 Schlimmes ahnen. Folgender Vorfall z.B. wurde im "Wall Street Journal" vom 25. November 1985 beschrieben:

Die "Bank of New York" war damals einer der grössten Vermittler von Käufen und Verkäufen von US-Staatsanleihen ("Treasury Bonds"). Am Donnerstag dem 21. und am Freitag dem 22. November 1985 wurde das Computersystem der Bank durch eine Fehlfunktion für fast 28 Stunden lahmgelegt.

Dadurch war die Bank in dieser Zeit nicht in der Lage, Anleihen an Käufer zu liefern und deren Zahlungen entgegenzunehmen. Resultat: Die Bank konnte Anleihen, die man ihr verkauft hatte, nicht bezahlen, weil ja kein Geld mehr hereinkam!

Noch am Donnerstag musste die Bank bei der "Federal Reserve Bank" notfallmässig 20 Milliarden Dollar Kredit aufnehmen, um flüssig zu bleiben. Obwohl der Kredit nach der Behebung des Computer-Problems und der Wiederaufnahme des Handels schnellstmöglich zurückbezahlt wurde, beliefen sich die Zinskosten auf 4 Millionen Dollars.

Details zu dieser Geschichte finden Sie unter http://catless.ncl.ac.uk/Risks/1.25.html#subj2 .

Hierzu gäbe es sehr viel zu sagen. Aber heute nur zwei kleine Bemerkungen: Im Vergleich zu heute üblichen Handels-Volumen war der Handel damals 1985 wohl nicht mehr als ein besseres Trinkgeld. Und: 28 Stunden sind eigentlich als Zeitspanne auch kaum der Rede wert. In 28 Stunden macht man auf jeden Fall kein Programm jahr-2000-fähig.

In Ihrer Firma gibt es auch eine Menge junger Schnösel, die alle besser bezahlt sind als Sie. Sie haben schon programmiert, als diese Jungs noch in die Windeln gemacht haben. Die sind ja sogar noch stolz darauf, dass sie nicht Cobol können.

Aber jetzt geschieht etwas Unerwartetes: Das Blatt scheint sich zu wenden. Das Jahr-2000-Problem zeigt sich am Horizont. Plötzlich sind Sie wieder wichtig, und es gibt wieder jede Menge für Sie zu tun. Ihr Chef verlangt nun von Ihnen den totalen Einsatz, denn die Zeit ist knapp.

Die Firma funktioniert nicht ohne die Mainframe-Programme. Die Programme sind nicht jahr-2000-fähig. Sie alleine kennen die Programme. Auch sonst sind Sie kaum zu ersetzen, denn Leute mit Mainframe- und Cobol-Erfahrung sind rar geworden in den letzten Jahren.

Kurz gesagt: Jetzt sind Sie dran.

Das soeben beschriebene Szenario ist vielleicht etwas überspitzt. Aber es stimmt im Grunde schon: Cobol als klassische Mainframe-Programmiersprache feiert im Moment eine ziemlich dramatische Renaissance. Weil die Nachfrage nach Leuten mit Cobol-Kenntnissen grösser ist als das Angebot, steigen die Gehälter, und zwar nicht zu knapp: je etwa 25 Prozent in 1996 und 1997.

Hier zwei schöne Schlagzeilen zu diesem Thema:

DEALS OF THE CENTURY
Year 2000 conversion projects could turn select IS professionals into corporate superstars
http://careers.computerworld.com/cwnews/current_articles/0337.html

Hunger for IT skills distorting salary structures
http://www.theage.com.au/daily/970812/infotech/infotech2.html

Cobol-Programmierer als Superstars und durcheinandergewirbelte Lohn-Skalen - wer hätte das gedacht.

Der IRS (Steuerbehörde der USA), von dem hier auch schon die Rede war, zeigt etliche Mühe beim Mithalten. 1997 verdoppelte sich die Fluktuation unter den Programmieren des IRS im Vergleich zu 1996 - auf deutsch: die Leute drohen davonzulaufen.

Um dem entgegenzuwirken, hat der IRS kürzlich für 1998 eine 10-prozentige Lohnerhöhung beschlossen (siehe http://www.gcn.com/gcn/1998/March23/cov3.htm ). Mein Kommentar: Wow, 10 Prozent! Bin ja so gespannt, ob das was bringt.

Wenn Sie auf einer Konservendose geschrieben sehen: "zu konsumieren bis 05.07.01", werden Sie ohne Probleme verstehen, was mit "01" gemeint ist: das Jahr 2001. Und wenn Ihre Kreditkarte sagt, "expires 12-31-00", ist es für Sie wieder kein Problem, in "00" das Jahr 2000 zu erkennen.

Man sieht also, dass man Jahreszahlen gar nicht unbedingt vierstellig führen muss. Es genügen zweistellige Jahreszahlen, unter der Bedingung, dass man eine kleine Zusatzregel einführt, wie eine bestimmte Zahl zu interpretieren ist. Beispiel: Zahlen von "00" bis "09" als 2000 bis 2009, und Zahlen von "10" bis "99" als 1910 bis 1999.

Haben wir hier die wunderbare Lösung des Jahr-2000-Problems vor uns, die vielgesuchte "Silver Bullet"? Nun ja, diese Windowing genannte Technik wird tatsächlich angewendet, und es kostet in der Tat einiges weniger an Arbeit, ein Programm durch geeignetes Windowing jahr-2000-tauglich zu machen, als durch die Umstellung auf vierstellige Jahreszahlen.

Der Teufel steckt, wie so oft, erst im Detail: Man kann nicht für alle Jahreszahlen dasselbe Fenster verwenden. Geht es z.B. um Geburtstage, muss man möglichst weit zurück, um auch noch diejenigen alter Leute darstellen zu können, also etwa mit 1900 bis 2000 als Fenster. Geht es aber um das Ablaufdatum von Lebensversicherungen, muss man weit in die Zukunft kommen, während bereits lange ausbezahlte nicht mehr interessieren, also etwa mit 1990 bis 2089.

Natürlich kann man auch so programmieren, dass in ein und demselben Programm verschiedenartige Jahreszahlen mit unterschiedlichen Fenstern behandelt werden. Nur: Wie Sie sich unschwer vorstellen können, ist das eine ziemlich gefährliche und fehleranfällige Sache.

Und während man vielleicht die Situation für sich selbst unter Kontrolle bekommt, wird es erst richtig lustig, wenn Datumsangaben zwischen Programmen ausgetauscht werden. Sind sich die beteiligten Programme nicht einig über das Fenster, wird aus dem im Jahre 2000 geborenen Säugling ein 1900 geborener Hundertjähriger!

Hersteller von Tools für Jahr-2000-Umstellungen hängen verständlicherweise diese Probleme nicht an die grosse Glocke, sondern loben lieber die Vorteile der Methode. Siehe z.B. http://www.recyc2000.com/solu/method.html .

Als im Dezember letzten Jahres die "Chief Information Officers" aller US-Bundesbehörden zu einem Jahr-2000-Gipfel zusammenkamen, beschlossen sie u.a. aus solchen Gründen, dass für den Datenaustausch der Behörden untereinander nur vierstellige Jahreszahlen eingesetzt werden dürfen.

Einen Bericht über das entsprechende "Memorandum of Agreement" findet man unter http://www.garynorth.com/y2k/detail_.cfm/1046 . Die ganze Sache ist etwas pikant, weil dieser Beschluss reichlich spät kommt, nachdem verschiedene Behörden bereits jahrelang an der Arbeit sind, ihre Programme mittels Windowing zu reparieren...

Politiker wären aber nicht Politiker, wenn sie nicht irgendwo einen Kompromiss einbauen, der den eigentlichen Beschluss postwendend ad absurdum führt: Im Memorandum steht auch, wenn sich zwei Behörden miteinander über ein anderes Format einigen, sei das auch ok. Also alles in Ordnung, nicht?