Dass die meisten Unternehmen ihre Programmbestaende nicht in Ordnung halten und schlecht dokumentierte Altlasten mitschleppen, macht den Software-Crash wahrscheinlicher. Jetzt mit einer Inventur anzufangen und die Umstellung der Jahreszahlen mit anderen Aufgaben zu verbinden, empfiehlt Arnd Paehlig, Softwareberater und Mitglied der internationalen Task Force "Change of Century" bei CSC Ploenzke. Heidrun Haug* befragte ihn im Auftrag der COMPUTERWOCHE.
CW: Ist die Jahrtausendwende fuer die Informationsverarbeitung bedrohlicher als die Umstellung der Postleitzahlen vor drei Jahren?
Paehlig: Mit Sicherheit. Ein Datum steuert viele Dinge in unserem Leben, mehr als eine Postleitzahl, und ist DV-technisch ein wesentliches Informationsobjekt. Deshalb ist das Problem gewichtiger und vielschichtiger als bei den Postleitzahlen, zumal es fuer die Umstellung des Datums keine Uebergangsloesungen und auch keinen Parallellauf geben wird.
CW: Welche Unternehmen sind betroffen?
Paehlig: Im Prinzip alle, die Datenverarbeitung eingesetzt haben. Der Uraltwitz, dass EDV die Abkuerzung fuer Elektrische Datumsverarbeitung sei, wird wahr.
CW: Unabhaengig davon, ob die Anwender eine grossrechnerbasierte DV oder eine moderne Client-Server-Struktur haben?
Paehlig: Hier kann ich nur warnen: Das Jahr 2000 ist kein Host- Problem. Im Gegenteil: Je integrierter und/oder dezentralisierter die DV ist, desto groesser wird die Gefahr. Zum einen, weil man diese integrierten Systeme nicht einfach abloesen und ersetzen kann. Zum andern ist es in offenen, komplexen Infrastrukturen schwierig, die datumsrelevanten Felder zu lokalisieren. Die Jahreszahlen kommen in allen Betriebssystemen vor, in Netzwerken, Grossrechnern und in PCs. Darueber hinaus sind viele zeitabhaengigen, softwaregesteuerten Systeme gefaehrdet - beispielsweise Telefonanlagen, Zugangs- und Sicherheitssysteme.
CW: Man hoert hin und wieder, nur Cobol-Programme seien tangiert.
Paehlig: Das ist voelliger Quatsch. Das Datum ist kein Problem der Programmiersprache. Die Gretchenfrage lautet: Ist die Jahreszahl zwei- oder vierstellig dargestellt? Mit Sicherheit gibt es Cobol- Programme, die das Problem nicht haben. Ebenso sicher gibt es Tausende Anwendungen, die in C++, PL/1 oder einer modernen 4GL- Programmiersprache geschrieben wurden, aber das Jahr 2000 nicht verkraften werden.
CW: Also kein Anlass, Cobol zu verbannen?
Paehlig: Manche tun, als sei Cobol ein Relikt, das man sowieso besser aus der Welt schafft. Nur zur Erinnerung: In den Unternehmen gibt es jede Menge Programme, die in Cobol oder sogar noch in Assembler geschrieben sind. Man glaubt gar nicht, wie viele Uralt-Anwendungen noch ihren Dienst tun. Und ich bin sicher, dass Cobol auch die Jahrtausendwende ueberleben wird.
CW: Ist die Lage bei Software neueren Datums entspannter?
Paehlig: Die meisten neuen Programme greifen auf alte Datenbestaende zurueck oder tauschen mit Altsystemen Daten aus. Man muss bedenken, dass Informationsverarbeitung heute in aller Regel ueber das einzelne Unternehmen hinausgeht. Viele Betriebe kommunizieren per Edifact mit ihren Geschaeftspartnern. Das heisst, dass auch neue Software zweistellig verschluesselte Jahreszahlen verarbeiten koennen muss - und schon ist das Problem vererbt.
CW: Punkt 24 Uhr an Silvester 1999 geht also die Rakete los.
Paehlig: Irrtum, vorher. Denken Sie nur an Ihre Kreditkarte. Viele Anwendungen arbeiten mit zweijaehrigen Fristen. Diese Programme muessen spaetestens Ende 1998 modifiziert sein.
CW: Was empfehlen Sie?
Paehlig: Jeder IS-Manager sollte endlich das tun, was er seit Jahren immer wieder verschiebt: seine Programmbestaende ausmisten. Wir erhalten heute jederzeit Auskunft von den DV-Systemen, wie viele Schrauben des Typs xy im Lager liegen, fuer welchen Kunden welche Teile entnommen worden sind, kurz: Die DV gibt uns Aussagen ueber alles moegliche - nur nicht ueber sich selbst. Fragen Sie einen IS-Manager, wie viele Programme und wie viele Lines of Code er gespeichert hat, dann muss er passen.
Ein Beispiel: Wir haben kuerzlich bei einem Kunden den Softwarebestand durchforstet. Laut IS-Management waren dreihundert Anwendungsprogramme im Einsatz, nach der Analyse liess sich der Bestand auf weniger als hundert reduzieren. Da gab es Programme, die in sechs verschiedenen Versionen abgespeichert waren und auch gewartet wurden.
CW: Droht aus Mangel an Durchblick der Software-Crash?
Paehlig: Eine Inventur des Programm- und Datenbestandes ist ueberfaellig. Nicht nur im Hinblick auf das Jahr 2000. Jede Veraenderung, jede Abloesung wird zu einem Risiko, wenn die Bestaende nicht geordnet sind. Und der Wechsel ins naechste Jahrhundert ist ja nicht das einzige Ereignis, das vor uns steht. Denken Sie bloss an die Einfuehrung des Eurogeldes. Es gibt heute Verfahren und Werkzeuge, um die Probleme zu loesen. Als Stichworte nenne ich nur Change-, Versions- und Konfigurations-Management.
CW: Die Umstellung der Jahreszahl als Fleissaufgabe.
Paehlig: Eine technische Herausforderung ist die Aenderung der Datumsfelder eigentlich nicht. Aber man muss mit Sorgfalt vorgehen und analysieren, wo ueberall das Datum eine Rolle spielt. Dies setzt voraus, dass ein Anwender seine Programme kennt. Auf jeden Fall ist es eine undankbare Aufgabe. Der Wert der Software- Investitionen wird zwar erhalten, aber davon hat der Benutzer keinen unmittelbaren Nutzen, keine zusaetzliche Funktionalitaet.
CW: Was sollen die Anwender tun?
Paehlig: Wir empfehlen, fruehzeitig, am besten jetzt sofort, anzufangen und die Umstellung der Jahreszahlen mit einer Verbesserung der Softwarequalitaet zu verbinden. Fruehzeitig auch deshalb, weil bekanntlich jedes Projekt eine Planungsphase hat. Es dauert, bis der Aktivitaetenplan steht und Kapazitaeten, Ressourcen, Budgets etc. bewilligt sind.
CW: Skizzieren Sie bitte die Vorgehensweise.
Paehlig: Das Vorgehen sollte sich in mehrere Phasen gliedern. Ist das allgemeine Problembewusstsein vorhanden, geht es in der zweiten Stufe um die Inventur all dessen, was eingekauft oder selber entwickelt wurde: Programme, Files, Copybooks, Prozeduren, Job Control Lists. Gleichzeitig ist zu ueberlegen, wo das Datum eine groessere Bedeutung hat. Hier wird es erhebliche Unterschiede bei den verschiedenen Anwendern geben. Eine Bank wird es eher verschmerzen, wenn in einem hausinternen Report 00 anstatt 2000 steht, als wenn fuer einen Kunden die Zinszahlungen falsch berechnet werden. Die Klassifikation der Fehlerquellen ist die Basis fuer die Loesungsstrategie, die in der dritten Stufe erarbeitet wird.
CW: Heisst das, dass der IS-Manager fuer jede einzelne Anwendung eine Loesung entwickeln muss?
Paehlig: Es gibt ja verschiedene Ansaetze, um die Problemfelder in den Griff zu bekommen. Lohnt es sich, das Altsystem wei- terzupflegen, oder wird es besser verschrottet und abgeloest? Fuer die Abloesung, sei es durch ein Individual- oder Standardprogramm, braucht man Zeit, und man muss wissen, welche Funktionen das Altsystem erfuellt. Eine gruendliche Analyse jeder einzelnen Anwendung ist also unbedingt erforderlich. In dieser Phase faellt auch die Entscheidung, ob und gegebenenfalls wie die Datumsumstellung in eigener Regie durchgefuehrt wird.
CW: Welche Loesungswege gibt es?
Paehlig: Man unterscheidet zwischen dem Daten- und dem Logikansatz. Bei letzterem wird beispielsweise festgelegt, dass ein Datum mit den Endziffern zwischen 51 und 99 zum Jahr 1900 und alles zwischen 01 und 50 zu 2000 gehoert. Der Datenansatz erfordert etwas mehr Zeit, ist aber sicherer. Hierbei werden alle zweistelligen Jahreszahlen durch vierstellige ersetzt.
CW: Existieren Werkzeuge, die den Umstellungsprozess erleichtern?
Paehlig: Auf dem Markt gibt es vier Gruppen von Software-Tools, die in Frage kommen. Erstens Scanner, die den Quellcode eines Programms nach einer bestimmten Zeichenfolge durchsuchen und die gefundenen Stellen markieren. Impact-Analyse ist hierfuer der Fachbegriff. Intelligente Scanner sind in der Lage, Datensaetze verschiedener Programmiersprachen zu pruefen, und koennen darueber hinaus die Fundstelle analysieren, um so auch indirekt betroffene Felder aufspueren. Zweitens gibt es Datumsstandardroutinen, vorgefertigte Softwarebausteine fuer die Berechnung eines Datums. Nuetzlich koennen drittens Zeitsimulatoren sein.
CW: Wofuer?
Paehlig: Bei Host-Systemen ist das Systemdatum zentral im Supervisor gespeichert. Diese Systeme lassen sich nicht abschalten und mit dem neuen Datum testen. Simulationssoftware bietet die Moeglichkeit, den Datumswechsel in einer Testumgebung zu simulieren. Viertens sind Testwerkzeuge sehr wichtig.
CW: Ohne Werkzeuge geht es nicht?
Paehlig: Natuerlich kann man auch jedes Programm Zeile fuer Zeile von Hand durchforsten und das Datum aendern. Werkzeuge wie ein Scanner machen dies automatisch und koennen sehr hilfreich sein. Datenroutinen sind am preiswertesten, tragen aber auch am wenigsten zur Problemloesung bei. Auf das Testen mit Werkzeugen wuerde ich nie verzichten. Bei einem groesseren Programmbestand rate ich auf jeden Fall zu einer Tool-gestuetzten Vorgehensweise, weil ansonsten weder Effizienz noch Produktivitaet gewaehrleistet sind.
CW: Gibt es auch Faelle, wo Sie von einem Tool-Ansatz eher abraten?
Paehlig: Problematisch wird es bei sehr heterogenen DV- Landschaften. Wenn ein Unternehmen einige hundert Programme in zig Dialekten hat, ist jeder Rat schwierig.
CW: Wie geht's weiter, wenn die Prioritaeten festgelegt und die Werkzeuge ausgewaehlt sind?
Paehlig: Auf der Basis eines Aktivitaetenplans wird man Schritt fuer Schritt die Anwendungen aendern. Zum Schluss sind die modifizierten Anwendungen und Systeme einzeln und im Zusammenspiel zu testen. Ausserdem empfiehlt es sich, Konversionsprogramme fuer eine Uebergangszeit zu entwickeln, da wahrscheinlich nicht alle Anwendungen zum selben Zeitpunkt umgestellt werden.
CW: Was muessen Unternehmen bei der Projektorganisation bedenken?
Paehlig: Die Datumsumstellung ist ein Projekt wie jedes andere. Entscheidend ist, dass eine Person verantwortlich ist, die festlegt, was zu tun ist und wann welche Programme umgestellt werden. Und es ist sehr wichtig, dass die Geschaeftsfuehrung das Projekt mit oberster Prioritaet unterstuetzt.
CW: Mit welchem Aufwand muessen Unternehmen rechnen?
Paehlig: Mit dieser Frage treffen Sie einen Schwachpunkt. Es gibt nicht viele Erfahrungen. Sicher ist, dass sich das Problem nicht in ein paar Stunden und auch nicht in wenigen Tagen beheben laesst. Die SAP, die ein ausgefeiltes Konfigurations- und Versions-Management hat und ihr R/3 bestens kennt, hat Mannjahre im zweistelligen Bereich fuer dessen Anpassung benoetigt. Da laesst sich erahnen, was auf die Unternehmen zukommt.
*Heidrun Haug ist freie Journalistin in Tuebingen.
Kurz & buendig
Die Umstellung auf vierstellige Jahreszahlen ist nicht so sehr ein technisches Problem, sondern eins des Projektmanagements. Der Ploenzke-Mitarbeiter Arnd Paehlig zeigt auf, wie sich das Projekt in welche Arbeitsschritte gliedern laesst. Er klassifiziert die Werkzeuge, die bei der Durchfuehrung zum Einsatz kommen koennen, ja muessen. Denn hier handelt es sich, wie er ausfuehrt, um ein Projekt, das komplexer und personalaufwendiger ist, als die meisten Anwender erwarten. Auch Paehlig warnt vor weiterem Vor- sich-Herschieben der Aufgabe.
Zitate
"EDV - die Abkuerzung fuer elektrische Datumsverarbeitung."
"Schritt fuer Schritt die Anwendungen aendern." Arnd Paehlig, CSC Ploenzke