Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Problem 2000/Das Jahrtausendproblem auf die leichte Schulter genommen


26.01.1996 - 

"Dann bin ich eh in Rente" - Warner staunen ueber Ausreden

Ein Jahr lang zog Alex Bleier, Director Century Date Change Group bei der in Oakdale, Pennsylvania, residierenden Unternehmensberatung Mastech, mit Seminaren und Vortraegen quer durch die Vereinigten Staaten. Danach stellte er fest: "95 bis 98 Prozent der Unternehmen haben bisher nichts getan."

Als der Softwarehersteller Micro Focus Anfang Oktober 3000 Kunden in Deutschland zum gleichen Thema einlud, zeigten gerade einmal 40 DV-Manager Interesse. Dabei hat die Gartner Group hochgerechnet, dass es einzelne Firmen bis zu 40 Millionen Dollar kosten wird, ihre Software zu bereinigen.

Aber es brennt auch anderswo. Denn, so die Befuerchtung der Experten, die Wartungskapazitaeten in durchschnittlichen DV- Abteilungen reichen nicht aus, um das Problem zeitgerecht zu loesen. "Wenn man sich anschaut, was Wartungsprogrammierer gegenwaertig im jaehrlichen Mainte-nance-Zyklus modifizieren koennen, so sind das fuenf bis sieben Prozent", meint Bleier. "Hier geht es aber um 60 bis 70 Prozent des gesamten Sourcecodes."

Und, so fasst er zusammen: "Man muss sich ernsthaft fragen, ob die Aufgabe bis zum 1. Januar 2000 ueberhaupt zu bewaeltigen ist." Denn fatalerweise hat dieses Projekt eine unverschiebbare Deadline, es laesst sich nicht einfach zu einem "2001"-Projekt ummuenzen.

Je mehr Zeit verstreicht, desto groesser wird der fuer die Loesung benoetigte Personalaufwand. Aber es geht nicht in einem Kraftakt kurz vor Torschluss. Dem stehen schon die Tatsachen gegenueber, dass grosse Teams nicht steuerbar sind und der Aufwand fuer Koordination und Management mit der Zahl kleinerer Gruppen ueberproportional steigt.

Wie die Unternehmensberatungen Arthur Andersen oder James Martin hat Mastech zur Entschaerfung der "Timebomb Year 2000" eine Spezialistengruppe zusammengezogen, die ueber Satellitenleitungen mit indischen Offshore-Programmierern an der Entschaerfung ebenjener Zeitbombe arbeitet. Arthur Andersen Consulting bestaetigt Bleiers Aussagen. Die Berater haben ermittelt, dass bei einem Programmumfang von fuenf Millionen Lines of Code fuer die Aenderung zehn bis 20 Mannjahre Umstellungsaufwand noetig sind.

Zur Loesung des Problems sind alle Kuenste des Projekt-Managements gefragt. Gerard Otten von James Martin Consultants im niederlaendischen Utrecht raet: "Man muss sich die besten Leute suchen, ein Team von sechs bis acht Mann zusammenstellen und endlich anfangen - aber richtig." Er warnt davor, planlos vorzugehen. Vielmehr raten die James-Martin-Strategen, nach "Upgrade musts" zu suchen. Mit Applikationen, die strategische Bedeutung fuer das Unternehmen haben, sollte begonnen werden.

Bleier sieht da zusaetzliche Alternativen, ohne eine davon zu favorisieren: Entweder beginnt man mit einem relativ einfachen, ueberschaubaren und gut dokumentierten Programm: Learning by doing. Oder man beginnt mit dem aeltesten Programm. Ist das bereinigt, lassen sich vermutlich auch die Programme juengeren Datums entsprechend umstellen.

Allerdings empfiehlt Mastech fuer beide Loesungen die statistische Begleitung mit einem Masssystem fuer die Komplexitaet. Damit liessen sich fuer andere Systemkomponenten Dauer und Aufwand der Loesung beurteilen. Ausserdem sei so rechtzeitig zu erkennen, ob Hilfe von aussen noetig ist.

Wer nun denkt, er habe das Problem delegiert, weil er Standardsoftware verwendet, den belehrt Bleier eines Besseren: "Gerade in Grossunternehmen, die Standardsoftware einsetzen, sind viele Leute neben ihrer normalen Arbeit ueber Monate damit beschaeftigt, den Upgrade von einer Standardsoftwareversion auf die naechste vorzunehmen."

Wie langwierig und komplex die Loesung ist, bestaetigt Michael Smith von der Great American Insurance, die unter anderem auch Bonds mit einer Laufzeit von acht Jahren ausgibt. Er stiess deshalb mit seiner Truppe schon 1986 auf das Problem; angepackt hat er es dennoch erst 1992.

Smith setzte einen "Softwarepiloten" auf, um schon bei der Analyse des ersten Programms mit Entsetzen festzustellen, dass dessen Sanierung 53 Mannjahre dauern wuerde. Seine statistische Erkenntnis: Nur rund zehn Prozent des Codes, aber 90 Prozent der Logik in den Programmen sind betroffen. Und obgleich er seither mit allen Kraeften und vielen Werkzeugen an der Umstellung arbeitet, sind erst 70 Prozent der Aufgabe erledigt.

Durchaus gaengige Programmiererusancen erweisen sich jetzt als Fussangeln fuer ein schnelles Vorwaertskommen bei der Suche nach der 99 im Datumsfeld - etwa die, aus Speichergruenden eine 3-Byte- Darstellung gewaehlt zu haben. Hinzu kommen die Eigenwilligkeiten der zahlreichen Programmierer, die im Lauf der Jahre Mainframe- Systeme bearbeitet haben. Smith entdeckte ein Programm, an dem innerhalb von zwoelf Jahren 130 verschiedene DV-Mitarbeiter codiert hatten.

Auch andere Nachlaessigkeiten erschweren die Problemloesung: Experten schaetzen, dass bei Firmen in den USA bis zu fuenf Prozent des Sourcecodes nicht mehr vorhanden sind - beispielsweise weil Mitarbeiter ausgeschieden sind, Rechenzentren in der Zwischenzeit verlegt wurden oder weil ein Band sonstwie verlorenging und es keiner gemerkt hat.

Auch die Great American Insurance musste fehlenden Sourcecode rekonstruieren. Smith entschied sich angesichts der analysierten Probleme, den Weg des geringsten Risikos zu gehen: nirgendwo Aenderungen an der Logik, statt dessen Erweiterung des Jahresfelds auf vier Zeichen. "Das erschien uns als der sicherste Weg. Denn dies reduziert in unserem Fall grundlegende Aenderungen in den Programmen und in der Speicherverwaltung", so Smith.

"Wenn wir die Prozeduren und ihre Gliederung aendern und in die zugrundeliegende Logik eingreifen wollten, muessten unsere Mitarbeiter die Geschaeftsprozesse verstehen." Mit seiner Entscheidung gelang es ihm jedoch, den Grad der Erfahrung des Teams, das die Aenderungen vornimmt, auf "studentisches Know-how" zu druecken, was die Personalkosten erheblich reduzierte.

Um das Datumsfeld einer Software anzupassen, muss der Wartungsprogrammierer bei der Aenderung verstehen, wo in dieser Anwendung ueberall auf ein Datumsfeld Bezug genommen wird. Nur dann kann er danach suchen, was einmal Baujahr, dann Vertragsbeginn, ein anderes Mal Geburtsdatum oder Annuitaeten heisst. Das kann Hunderte von Bildschirmen, Reports und Datenbanken betreffen, die Zehntausende von Datenelementen enthalten. Der Aufwand ist mit der Zahl der Programme zu multiplizieren, die ein Unternehmen einsetzt.

"Zu Fuss" ist das nicht mehr zu machen, vor allem nicht in der verbleibenden Zeit. Deshalb schiessen jetzt "Year-2000-Werkzeuge" wie Pilze aus dem Boden. Die Berater von James Martin zaehlten fuer die Studie "Preparing Legacy Systems for the Turn of the Century" im Herbst 1995 rund 80 solcher Tools. Allgemeiner Rat: Die Werkzeuge muessen in allen Phasen dieser klassischen Maintenance- Aufgabe ineinandergreifen.

Und weil es schnell um fuenfstellige Summen geht, sollte so ein Werkzeug nicht nur zur Loesung des "Jahr-2000-Problems" taugen. Marco Policastro, Consultant bei Arthur Andersen, New York, sieht als ein Auswahlkriterium von Werkzeugen "den Analyseteil, um im Backtracing verfolgen zu koennen, wo ueberall Datumsfelder auftauchen". Mastech-Direktor Bleier glaubt: "Am meisten Geld kann sparen, wer sich ein starkes Test-Tool beschafft. Denn im wesentlichen laufen die Anwendungen, aber sie muessen auch nach der Modifikation laufen."

Alsdann - Sonntage weggerechnet, bleiben von jetzt an noch gut 1200 Tage, um das Problem zu loesen. Aetzender Trost kommt aus der Ecke der Zyniker. Der 1. Januar 2000 faellt auf einen Samstag. Da ist noch ein volles Wochenende, um das Ganze in Griff zu bekommen.

Die beste Satire liefert wieder einmal die Realitaet: Micro Focus hat ein Papier "Challenge 2000: Assessment Toolkit" herausgegeben. Es enthaelt unter anderem die sieben gebraeuchlichsten Antworten von DV-Chefs, warum sie noch nichts zur Loesung des Problems unternommen haben. Eine lautet: "Das geht mich nichts an. Ich werde am 1. Januar 2000 nicht mehr in diesem Unternehmen taetig sein."

*Elmar Elmauer ist freier Journalist in Scheidegg, Allgaeu.

Schaltjahr 2000?

Die seit 1582 von Papst Gregor festgelegten Regeln fuer die moderne Datumszaehlung nach dem Gregorianischen Kalender besagen:

Grundregel: Schaltjahre sind glatt, also ohne Stellen nach dem Komma, durch vier teilbare Jahre.

Ausnahme: Ein durch 100 glatt teilbares Jahr wie 1700, 1800 oder 1900 ist kein Schaltjahr.

Ausnahme von der Ausnahme: Jahreszahlen, die sich glatt durch 400 teilen lassen, sind wiederum Schaltjahre.

Folglich ist das Jahr 2000 ein Schaltjahr, ebenso wie die Jahre 2004 oder 2400 Schaltjahre sind. E. Elmauer

Kurz & buendig

Berater ziehen uebers Land, Softwarehaeuser veranstalten serienweise Seminare. Doch sie bleiben einsame Rufer in der Wueste. Irritiert ziehen die Warner die Bilanz, dass die Anwender erstaunlich ungeruehrt zu sein scheinen. Eine der haeufigsten Ausreden fuer Nichtstun ist allen Ernstes, im Jahre 2000 sei man ohnehin nicht mehr in der jetzigen (DV-Leiter-)Position. Ernsthaftere DV- Verantwortliche, die ihre Software analysiert haben, fielen aus allen Wolken.