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.

15.03.1996 - 

Problem 2000/Nur ein Riesenproblem oder auch eine Herausforderung?

Die Jahreszahlen-Umstellung: Was Anwender beachten sollten

Ein Datum taucht ueberall auf: in Anwendungsprogrammen, in allen Softwarekomponenten, ja sogar in der Hardware. Gegenueber der Postleitzahlen-Umstellung faellt bei der Jahrtausendumstellung ein Vielfaches an Aufwand an, und das Risiko bei Fehlern laesst sich ohne naehere Untersuchung kaum kalkulieren. Qualifiziertes Personal steht fuer den zusaetzlichen Arbeitsaufwand nicht ohne weiteres zur Verfuegung, und auf den falschen Anbieter von Loesungen zu setzen koennte verhaengnisvolle Konsequenzen nach sich ziehen. Aller Voraussicht nach wird dies zu erheblichen Preissteigerungen fuer Jahr-2000-Loesungen fuehren.

Sollte man alle Programme und Daten aendern? Alle betroffenen Komponenten von der zwei- in die vierstellige Form umzuschreiben ist zwar die technisch sauberste, aber unbestritten auch teuerste Variante. Die Kosten fuer das Beheben des "Doppelnull"-Problems fallen deshalb so schmerzhaft ins Gewicht, weil im Gegenzug keinerlei Nutzen entsteht: Die Systeme laufen genauso gut oder schlecht wie bisher.

Bei aelteren Datenhaltungssystemen ist diese Erweiterung gar nicht so trivial, wie es scheint. Technische Gruende wie zum Beispiel mangelnder Platz im einzelnen "Record" verhindern bei den Erblasten eine einfache Loesung.

Bildschirmmasken, die vor Information nur so strotzen, bieten keinen Platz fuer vierstellige Zahlen: Der Aufwand fuer ein Redesign steht in keinem Verhaeltnis zum tatsaechlichen Nutzen. Zumal wenn der Anwender mit der Anzeige "01.01.00" gut leben kann, ist im Einzelfall zu pruefen, ob eine Aenderung ueberhaupt in Betracht kommt.

Bei Datenhaltungssystemen gibt es Routinen, die in den meisten Unternehmen auch im Einsatz sind und dem zweistelligen Jahreswert entsprechend einer vorgegebenen Grenze - beispielsweise groesser als 80 - das richtige Jahrhundert zuordnen. 84 ist 1984, 04 bedeutet 2004. Solche kostenguenstigen Loesungen sollten immer dann in Erwaegung gezogen werden, wenn Anwendungen ueber das Jahr 2000 hinaus laufen muessen, mittelfristig aber ohnehin zur Abloesung anstehen.

Der wichtigste Aspekt aber ist die generelle Senkung der Kosten fuer den Jahrhundertwechsel. Ein lohnender Ansatz waere es, bestehende Anwendungen und Datenbanken einem Re-Engineering zu unterziehen oder gleich abzuloesen, neue Systeme und Technologien einzufuehren und dabei nie das Datum-2000-Problem aus den Augen zu verlieren.

Dazu ist es erforderlich, so schnell wie moeglich eine unternehmensspezifische Strategie zu entwickeln, die zu allen aufgezeigten Problemen auch eine ueberzeugende Loesung bietet. Je mehr Zeit verstreicht, desto weniger Raum bleibt fuer Alternativloesungen, die dem Unternehmen zugleich einen konkreten Gegenwert bringen.

Als ein Beispiel dafuer lassen sich Cobol-Programme nennen: In den neuesten Compilern sind bereits Hilfsfunktionen integriert, die die Jahrhundertumstellung unterstuetzen und damit den Migrationsaufwand reduzieren helfen. Aber auch Loesungen fuer Datenbank- und Sprachmigrationen - wie von Assembler zu Cobol - kommen in Betracht. Wenn die uebergreifende Strategie nicht ohne Analyse zum Einsatz kommen kann, etwa weil die erforderlichen Informationen ueber die Verwendung des Datums nicht vorliegen, laesst sich dieser Schritt nach einer entsprechenden Feinanalyse durchfuehren.

Welche Aufgabenstellungen und Loesungsanforderungen ergeben sich bei der Programmumstellung? Kompliziert und aufwendig gestaltet sich das Problem insbesondere bei Firmen, deren IT-Landschaft ueber Jahrzehnte, womoeglich in widerspruechlichen Spruengen, gewachsen ist. Hierzu einige Kennzahlen eines repraesentativen Unternehmens:

-Genutzt wird ein Mix aus etwa 15000 Cobol-, PL/1- und Assembler- Programmen.

-Man verfuegt ueber unterschiedliche Rechnerarchitekturen, verschiedene Datenhaltungssysteme und Hunderte von Fremdsoftwareprodukten.

-Es gibt eine grosse Anzahl interner und externer Schnittstellen; teilweise sind die Anwendungen hochintegriert.

-Wo in diesen Komponenten das Datum in welcher Form auftaucht und wie es weiterverarbeitet wird, ist in der Regel nicht ausreichend bekannt und dokumentiert.

In dem angenommenen Fall von 15000 eingesetzten Programmen sind nach IBM-Untersuchungen etwa zwoelf Felder pro Programm zu korrigieren. Es gibt also insgesamt 180000 Stellen, an denen ein Eingriff erforderlich ist. Folglich geht es bei der Loesung zum einen um Massenverarbeitung. Zum anderen sollte bei der Umstellung das Prozess-Management eine hohe Prioritaet erhalten.

Ohne die geeigneten Werkzeuge laesst sich das komplexe Vorhaben kaum bewaeltigen. Selbst ein ueberzeugendes Set aus Re-Engineering- Werkzeugen, mit dem ein Programmierer rund 150 Programme erfolgreich bearbeiten kann, waere bei 15000 Programmen nicht ausreichend. Darueber hinaus sind Anwendungen zu analysieren, die in allen moeglichen Programmiersprachen geschrieben sind.

15000 Programme lassen sich auch nicht zur gleichen Zeit unter Kontrolle bringen. Zuerst waere die gesamte IT-Landschaft in handhabbare Bloecke (Stichwort Partitionierung) zu unterteilen, die sich dann einzeln bearbeiten lassen. Zur Unterstuetzung ist der Einsatz von speziellen Tools empfehlenswert.

Wie findet man die Datumsfelder, die zu aendern sind? Wer mit allgemeinen Hilfen wie "Pattern matching" arbeitet, findet bei der Suche mit JAHR* auch eine JAHRESTABELLE, die kein Problem fuer den Jahrhundertwechsel darstellt. Auf der anderen Seite aber bleiben Felder unidentifiziert, wenn Jahresinhalte auf "nichtsprechende" Namen wie zum Beispiel HUGO lauten. Fuer eine feinere Analyse sind Werkzeuge sinnvoll, die exakt jene Stellen identifizieren, die geaendert werden sollen.

Bei ersten Analysen haben Kenner der Materie etwa 20 bis 30 Prozent ueberfluessige Identifikationen gefunden, was einen erheblichen Mehraufwand bei einer spaeteren Migration zur Folge haette. Andererseits fielen durchschnittlich zehn bis 20 Prozent nichtidentifizierte Felder durch das Sieb.

Untersucht man die zeitliche Verwendung des Datums in den Systemen, arbeiten rund 70 Prozent mit dem heutigen Datum, etwa fuenf Prozent mit vergangenen und 25 Prozent mit zukuenftigen Zeiten. Bei unserem Durchschnittsunternehmen gehen am 01.01.2000 dann 70 Prozent beziehungsweise 126000 der in den Systemen vorhandenen 180000 Datumsfelder in einen Status ueber, der in der Regel durch die Doppelnull dargestellt wird und ohne Korrektur zu Fehlern fuehren kann. Wuerden davon 20 Prozent bei der Analyse nicht identifiziert, waeren dies potentielle 25200 Fehlerquellen. Das Chaos waere perfekt.

Die nicht gefundenen Items durch Tests zu evaluieren ist nahezu unbezahlbar und obendrein auch nicht erforderlich. Dazu gibt es Re-Engineering-Werkzeuge wie das von IBM eingesetzte "Cosmos", die die Trefferquote auf 99 Prozent hochschrauben.

Sind die tatsaechlich zu modifizierenden Items exakt identifiziert, bieten sich mehrere Alternativen an. Das Beste waere, die Auswirkungen sind analysiert und Anwendungen koennen unveraendert weiterlaufen, weil das Risiko vergleichsweise gering ist.

Doch meist duerfte die Lage ernster sein. Bei allen Migrationen sollte die Moeglichkeit bestehen, die Analyseergebnisse in eine bereits vorhandene Entwicklungsumgebung einzuspielen, sofern dies gewuenscht wird und dazu auch genug Personal zur Verfuegung steht. In der Regel sollte die Umstellung weitgehend automatisch erfolgen, wozu sich einige Werkzeuge anbieten.

Eine besondere Bedeutung fuer die Migration auf den Zustand "Y2000- clean" besitzen die Schnittstellen-Problematik und die daraus hervorgehende zeitliche Komponente. Zahlreiche DV-Anbieter ueberarbeiten derzeit ihre Produkte und werden sie zu verschiedenen Zeitpunkten "Year-2000-compliant" auf den Markt bringen.

Anwenderunternehmen sollten daher wissen, zu welchem Zeitpunkt welches Angebot mit datumsrelevanten Schnittstellen von den einzelnen Herstellern zur Verfuegung stehen wird, um diese Informationen in den Zeitplan bis zum Jahr 2000 einzubauen. Sie sollten ihre Lieferanten umgehend darauf ansprechen. Gleichzeitig muessen auch die Schnittstellen zu externen Partnern abgestimmt werden, eine Aufgabe, die sicherlich den gesamten Zeitraum bis zum Jahr 2000 beanspruchen wird.

Zahlreiche DV-Hersteller offerieren unterschiedliche Servicekonzepte fuer die Jahreszahlenumstellung. Sie reichen von Assessment einschliesslich Entwicklung einer Jahr-2000-Strategie ueber Impact-Analyse mit Partitionierung und Kostenschaetzung, Feinanalyse, Migration und Testunterstuetzung bis hin zur Hilfe bei der Produktionseinfuehrung.

Dennoch gibt es spezielle Probleme, die sich mit Standard-Tools nicht loesen lassen, etwa wenn kein Sourcecode vorliegt. Ausserdem existieren in jedem Unternehmen individuelle Anforderungen, die in der Regel "von Hand" angegangen werden muessen - dies erfordert zusaetzliche Zeit.

Transformation 2000: Es ist nicht zu frueh, aber bald zu spaet. Es sei jedem Unternehmen dringend empfohlen, unverzueglich mit der Entwicklung einer tragfaehigen Strategie zur Loesung der Probleme zu beginnen. Ein betraechtlicher Teil der Aufwendungen laesst sich sicherlich ueber vorhandene Pflege- und Wartungskapazitaeten oder auch ueber alternative Projekte abdecken.

Unter diesen Voraussetzungen ist die Aufgabe als Herausforderung und Chance anzusehen. Denn parallel gilt es, sich schon jetzt mit der anstehenden Euro-Waehrung zu befassen, deren Einfuehrung am 1. Januar 1999 beginnt und zum 1. Januar 2002 abgeschlossen sein soll. Sobald die Gesetze dazu verabschiedet sind, gibt es akuten Handlungsbedarf.

Kurz & buendig

In Logistiksystemen fuehren zweistellige Jahreszahlen zu besonders schmerzhaften Problemen, weil hier das Datum eine ueberragende Bedeutung hat. Es steuert Kalkulationen, Angebote, Auftraege, Lieferungen, Materialbedarfsplanung, Lagerverwaltung etc. Dass die Unternehmens-DV vielerorts Jahreszahlen ab dem Jahr 2000 als "00" und damit als vergangen liest, schafft gravierende Schwierigkeiten. Da es in der Logistik um laengerfristige Aufgaben geht, ist eine Umstellung auf vierstellige Jahreszahlen besonders dringend.

*Helmut Wolf ist Projektleiter Datum 2000 im IBM-Servicezentrum Komplexe Loesungen in Frankfurt am Main.