Hans Georg Bein, Leiter Methoden und Verfahren, Barmer Ersatzkasse, Wuppertal:

Die Datumsumstellung ist in unserem Unternehmen ein hochaktuelles Thema. Unser Interesse ist derzeit darauf gerichtet, herauszufinden, wie und unter welchen Randbedingungen die Jahrtausendproblematik bewältigt werden kann. Dabei favorisieren wir den methodischen Ansatz einer zu 100 Prozent automatisierten Konvertierung.

Aufgrund der aktuellen Projektsituation in unserem Haus haben wir Ende letzten Jahres die Bietergemeinschaft MDS/CGI beauftragt, eine Durchführbarkeitsstudie zu erstellen. Diese beinhaltet die Analyse der zirka 5000 PL/1-, Cobol-, Assembler und CSP-Programme auf Datenfelder, die in irgendeiner Form Datumsinformationen verarbeiten. Außerdem werden sämtliche Datenstrukturen analysiert, die Testverfahren für die bereinigten Programmstrukturen beschrieben, die Funktionalität aller untersuchten Programme sichergestellt und die Ausschreibungsunterlagen ausgearbeitet.

Ferner soll die Studie aufzeigen, wo Veränderungen in den Datenbeständen vorzunehmen sind, welche Modifikationen an den Daten-Schnittstellen vom DPPX- zum MVS-Umfeld anstehen, wie die Programme aussehen, die die "neuen" Datenbanken laden und wie beziehungsweise mit welchem Aufwand sich die Veränderungen durchführen lassen.

Bei der Analyse der Programme werden die kritischen Datenfelder ermittelt und das Konzept für die Umstellung entwickelt. Dabei werden auch die Datenstrukturen, Bildschirmmasken und Job-Control-Anweisungen analysiert und die Konvertierung der Strukturen und Masken geplant.

Auf die Analyse folgt die Klassifizierung der Programme in drei Kategorien:

-Anwendungen, die mittels eines Konverters zu 100 Prozent maschinell an den Jahrtausendwechsel angepaßt werden können,

-Anwendungen, die ganz oder zum Teil von Hand angepaßt werden müssen, und

-Programme ohne Anpassungserfordernisse.

Kritisch sehen wir die Daten- und Programm-Schnittstelle zwischen den DPPX- und den zentralen MVS-Programmen, da diese nicht zeitgleich umgestellt werden können. Ende September dieses Jahres werden wir das Ergebnis der Studie präsentiert bekommen. An die Ausschreibung wird sich die Realisierungsphase anschließen. Die Datumsumstellung wird uns in Schwung halten, zumal die Migration von unserer DPPX-Plattform - IBM stellt die Wartung 1998 ein - auf AIX und die Einführung der Euro-Währung für uns ebenfalls große Kraftanstrengungen bedeuten.

Dr. Manfred Hader, Leiter Anwendungsentwicklung der IBO GmbH, die als IBM-Outsourcing-Tochter die Datenverarbeitung der Frankfurter Lurgi AG betreut:

Wir haben für die Lurgi AG eine erste Analyse der betroffenen Systeme vorgenommen. Maßnahmen sind aber noch nicht geplant. Wir wissen recht genau, welche Systeme angepaßt werden müssen, haben aber noch keine konkrete Vorstellung vom Gesamtumfang. Sicher ist, daß wir mit dem SAP-System R/2 von der Version 4.3i auf 5.0 beziehungsweise auf R/3 gehen müssen.

Cobol-Anwendungen gibt es bei uns nicht, wir haben vorwiegend PL/1- und Assembler-Programme im Einsatz. Wir wissen bereits, wo Datumsformate vermutlich zwei- oder dreistellig verarbeitet werden und wo sie interpretiert, also durch Programme etwa im Bereich Projekt-Management als Ordnungskriterien herangezogen werden.

Wir sind darauf vorbereitet, daß das Jahr 2000 kommt - so lustig sich das anhört. Die Pläne unseres Kunden, in eine Client-Server-Umgebung zu wechseln, gehen über das Jahr 2000 hinaus. Wo aber die Datumsumstellung ansteht, wird sie rechtzeitig vorgenommen.

In wenigen Fällen ist eine Anpassung auf Codeebene geplant. In der Regel entwickeln wir neu oder setzen Standardsoftware ein. Daher müssen wir also nur genau wissen, welche Systemteile wie auf neue Strukturen abgebildet werden sollen.Norbert Barth, DV-Leiter der Aachener und Münchner Versicherungs AG in Aachen:

Versicherungsunternehmen haben noch vor drei, vier Jahren Verträge mit zehnjähriger Laufzeit abgeschlossen. Deswegen mußten wir schon Anfang der 90er Jahre in unseren Systemen den Jahrtausendwechsel vornehmen, denn es gab Verträge, die bis ins Jahr 2002 laufen.

Rund 80 Prozent unserer Programme betreffen solche versicherungstechnischen Aspekte. Sie beziehen sich auf Hausrat-, Unfall-, Wohngebäudeversicherungen etc. - den gesamten Privatkundensektor.

Wir werden also einen überschaubaren Aufwand haben, vor allem in den Bereichen Statistik und Rechnungswesen, wo wir Eigenentwicklungen einsetzen. Für eine automatische Umstellung der Programme haben wir keine geeignete Software gefunden. Wir werden das wohl manuell machen.

Ich schätze, daß der Aufwand bei fünf bis zehn Mannjahren liegen wird. Die Anpassungen sollen in den nächsten Monaten nebenbei erfolgen - parallel zu fachlichen Veränderungen der Programme.

Kritischer sehe ich die Einführung der Euro-Währung, auch wenn sie DV-technisch sicher nicht so aufwendig ist wie die Datumsumstellung. Ich gehe aber davon aus, daß uns erst sehr spät die Verfahrensregeln bekannt sein werden und wir deswegen unter Termindruck geraten.

Der Gesetzgeber hat sich in Deutschland ja bisher nicht klar darüber ausgesprochen, wann der Euro definitiv eingeführt wird und wie damit umzugehen ist. Wird der Kunde beispielsweise die Wahlfreiheit haben, die Prämie für sein Auto in Mark oder in Euro zu zahlen?

Die Unklarheit, die da im Augenblick noch herrscht, macht mir ein wenig Sorgen. Aber ich denke, auch dieses Problem ist lösbar. Ende August setzen wir uns mit Mummert & Partner zusammen, um uns zu beraten, wie wir dabei vorgehen.Günter Brettel, stellvertretender Leiter Informatik bei der HUK-Coburg:

Wir haben vor einiger Zeit mit der Problemanalyse begonnen, können aber noch keine Aussage über die Anzahl betroffener PL/1- und Assembler-Programme machen - auch nicht dazu, wie viele Lines of code modifiziert werden müssen. Eine Projektgruppe setzt sich mit diesem Thema auseinander. In der Analysephase ist eine externe Firma eingebunden.

Das Projekt Jahr 2000 genießt bei uns höchste Priorität. Es ist nicht auszuschließen, daß andere Vorhaben und Investitionen dadurch zurückgestellt werden müssen. Wir gehen davon aus, daß es sich um ein aufwendiges Projekt handelt, deshalb haben wir ihm absoluten Vorrang eingeräumt. Die Hinweise von Beraterfirmen sollten ernstgenommen werden.

Etwas Panikmache sorgt zumindest dafür, daß das Thema nicht unterschätzt wird. Die firmenspezifischen DV-Landschaften sind in keine Schablone zu pressen. Jedes Unternehmen muß den zu betreibenden Aufwand selbst ermitteln und einschätzen.

Jens-Peter Brand, Leiter Controlling und EDV bei der Ingenieurgesellschaft Schreiber, Brand und Partner, Prüfstands- und Industrieanlagen-Gesamtplanung, Lampertheim:

Nach bisherigem Wissensstand müssen wir keine Programme umstellen. Wir haben hier vor allem CAD-Anwendungen, in denen keine Automatismen auf Datumsfelder zurückgreifen. Ansonsten verwenden wir Microsoft-Standardprogramme wie Excel, in denen das Problem nicht besteht. Ich werde allerdings die Stand-alone-Systeme darauf überprüfen, ob das BIOS beim Jahr 2000 mitkommt. Im übrigen sind die Systeme mit einem Netware-Server vernetzt, der über eine Funkuhr gesteuert wird. Probleme könnte vielleicht ein Unix-System bereiten, aber ich vermute, daß es das Jahr 2000 ohnehin nicht erleben wird.

Bei allen neuen Fremdprodukten, egal ob Software oder Hardware, werden wir darauf achten, daß uns zweistellige Jahreszahlen bei der Nutzung nicht in Schwierigkeiten bringen können. Das gilt natürlich auch für die Anwendungen, die wir selbst schreiben.

Was die geplante Anschaffung eines Controlling-Systems betrifft, werden wir uns für ein Produkt entscheiden, das die Umstellung auf den Euro bewältigen kann. Falls das jetzt noch möglich ist, werden wir es vom Anbieter bis zur Einführung der neuen Währung verlangen.

Eva Unverferth, Leiterin Pharma-Informatik bei der Boehringer Mannheim GmbH:

Wir haben Programme von zwei- auf vierstellige Jahreszahlen umstellen müssen. Dies ist bei unseren dezentralen Systemen abgeschlossen, und mit den unternehmensweiten Umstellungen sind wir auch schon fast durch. Wir haben die in unserem Bereich eingesetzten dezentralen DV-Systeme, im wesentlichen fünf größere, auf das Datumsproblem überprüft. Vierstellige Jahreszahlen waren in ihnen im wesentlichen schon vorgesehen.

Letztlich sind es nur zehn Schnittstellen-Programme zu unternehmensweiten Systemen gewesen, an denen wir Änderungen vornehmen mußten. Dabei handelte es sich durchweg um Eigenentwicklungen von Schnittstellen zum unternehmensweiten R/2-System von SAP. Bei diesem ist die Umstellung fast fertig.

Bei den erwähnten fünf großen dezentralen Systemen lag der Aufwand bei insgesamt zehn Arbeitstagen. Wir haben die Analyse und die Sanierung ohne Fremdprodukte, nur mit eigenen Kapazitäten und Mitteln, erledigt. Eine Unterstützung durch Berater war auch nicht nötig.

Die Umstellung hat im Pharma-Bereich die Umsetzung der DV-Strategie, Entwicklungspläne oder Investitionsvorhaben nicht hinausgezögert. Sie hat diese allenfalls insofern beeinflußt, als wir jetzt die Verwendung vierstelliger Jahreszahlen für Eigenentwicklungen und neu zu beschaffende Fremdprodukte als Anforderung festgeschrieben haben.

Eine Katastrophe droht...

... nach Ansicht aller Marktanalysten den Anwendern. Die Einführung der Jahrhundertbenennung in alte DV-Programme werde sich zur finanziell aufwendigsten Maßnahme in der Geschichte der DV entwickeln. Die bekannten Kostenkalkulationen sind horrend.

Die Marktauguren sind sich aber alles andere als einig. Bis um den Faktor zehn liegen ihre Kostenschätzungen auseinander. Die Gartner Group rechnet mit globalen Kosten von 300 bis 600 Milliarden Dollar. Das Marktforschungsunternehmen Input wird in diesen Tagen eine Studie vorstellen, die "nur" 56 Milliarden Dollar für die Anpassung der Programme weltweit veranschlagt.

Ob aufwendig oder nicht, mit dem Problem 2000 werden sich die Unternehmen beschäftigen müssen. Weil bis in die 70er Jahre Speicherplatz teuer und daher knapp war, haben Programmierer einst die zwei Stellen für das Jahrhundert gespart. Doch ab dem Jahr 2000 (00) führen alle Differenzberechnungen zu zweistellig benannten Vorjahren, wie etwa 96, zu absurden Ergebnissen.

Menschen sind den Umgang mit zweistelligen Jahreszahlen gewohnt, sie werden damit auch jenseits des Jahres "99" kein Problem haben. Die digitalen Zahlenfresser sind hingegen fantasielos. Ihre Programme verlangen nach einem Hinweis auf den Jahrhundertwechsel. Besonders häufig sind Assembler-, Cobol- und PL/1-Applikationen betroffen, aber selbst in der Hardware kann das Problem lauern. "Hier und dort zwei Bytes mehr" sind aus verschiedenen technischen Gründen alles andere als eine banale Aufgabe.

Die COMPUTERWOCHE berichtete (vgl. CW Nr. 4 vom 26. Januar 1996, Seite 1 und 31 bis 46, und CW Nr. 11 vom 15. März 1996, Seite 74 bis 80) und handelte sich dafür den Vorwurf der Panikmache ein. Eine verbreitete Meinung: Das könne ja in den USA ein schweres Problem sein, denn dort sei eben immer schon "quick and dirty" programmiert worden. Hierzulande aber habe man ruhiger, überlegter und ergo einfach besser gearbeitet.

Dieser These widerspricht Lutz-Rainer Preuß, Geschäftsführer des Konvertierungs- und Re-Engineering-Spezialisten HAL Informatica aus Rehlingen. Nach 30 Jahren internationaler Erfahrung bei IBM wisse er, daß man letztlich auf beiden Seiten des Atlantiks gleich gut oder schlecht programmiert habe. "Quick-und-dirty-Programmmierung entspringt nie einer Planung, sondern der Notwendigkeit, bei im allgemeinen großem Anwendungsstau kurzfristig und vorübergehend eine Lösung zu schaffen. Leider haben solche Lösungen überall großes Beharrungsvermögen."

Über etliche Fälle, in denen Programme aufgrund des "Problems 2000" irreführende Ergebnisse geliefert haben, berichteten auch deutsche Anwender der COMPUTERWOCHE - allerdings "vertraulich". Schließlich wollen sie nicht in den Verdacht kommen, unsauber programmiert zu haben. ls

US-Anwender zum Problem 2000

"Gibt es Datumsfelder mit den Inhalten "00" oder "99", die nicht eine Jahreszahl bedeuten?"

Ja: 80, Nein 20

Zusätzliche Falle: Datenfelder werden als Jahreszahlen interpretiert, sind es aber nicht.

Quelle: Adpac, November 1995