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/Tips zur Wahl der Analyse- und Umstellungs-Tools


25.04.1997 - 

In deutschen Softwarelandschaften wuchert besonderes Unkraut

Ein paar Vorüberlegungen können eine Menge Arbeit sparen. Zunächst einmal ist zu entscheiden, welche Eigen- und welche Fremdsoftware noch nach dem Jahr 2000 laufen soll. Drei Jahre vor dem Stichtag ist davon auszugehen, daß der größte Teil der eigenentwickelten Softwarepakete betroffen ist - es sei denn, man steht unmittelbar vor der Einführung eines alternativen Systems.

Bei Fremdsoftware stellt sich die Frage, ob der Hersteller ein Jahr-2000-fähiges Update ausliefert. Dies führt nicht selten geradewegs in eine Wartungsproblematik, denn oft sind entsprechende Verträge ausgelaufen. Etliche Anwender dürften feststellen, daß sie Software verwenden, deren Lieferant längst vom Markt verschwunden ist.

Nur selten ein komplettes Outsourcing

Eines der wichtigsten Ziele der Inventarisierung liegt in der Aufstellung von Prioritäten bei den erforderlichen Umstellungsarbeiten. Dabei gilt es zu berücksichtigen, wie weit eine Software "nach vorne sieht". Prognoseprogramme, die beispielsweise eine Vorausschau von drei Jahren bieten, arbeiten bereits ab 1998 fehlerhaft. Sie stehen als erstes zur Renovierung an.

Möglichst früh sind darüber hinaus Systeme zu analysieren, die auf alten Compilern basieren - beispielsweise auf Cobol-74-Compilern, die nicht mehr unterstützt werden. Da sie in der Regel ab 2000 nicht mehr laufen dürften, sind im Vorfeld der Sourcenumstellung eventuell sogar neue Compiler-Releases vonnöten.

Erst nach einer umfassenden Inventarisierung läßt sich sagen, für welche Programmsets eine Problem-2000-Behandlung nötig ist. Außerdem sollte dann feststehen, wie umfangreich die zu überarbeitenden Bestände sind. Die Möglichkeiten schwanken zwischen 100000 und 40 Millionen Codezeilen. Eine typische Umstellung in einer Großrechnerumgebung wird sich mit mehr als einer Million Zeilen beschäftigen.

Im Anschluß an die Inventarisierung stehen viele Unternehmen vor der grundsätzlichen Frage, ob sie die Analyse und Problembehebung intern oder extern abwickeln. Nur sehr wenige werden sich dabei für ein komplettes Outsourcing entscheiden.

Es kommt allenfalls im Rahmen eines gesamten Outsourcings des Rechenzentrums in Betracht. In allen anderen Fällen erweist sich ein durchgängiges Outsourcing von Jahr-2000-Projekten als unpraktikabel. Außerdem erschwert es weitere Entwicklungs- und Pflegearbeiten.

Hierfür sind zwei Gründe maßgeblich:

- Problem-2000-Vorhaben bieten erstens den Nebeneffekt, daß der Analyseprozeß verlorengegangene oder verstreute Dokumentationen über die Softwarebestände wieder in aktueller und strukturierter Form erzeugt. Soweit diese Informationen innerhalb eines Unternehmens anfallen, stehen sie den Mitarbeitern für fortlaufende Wartungsarbeiten und vergleichbare Projekte, wie die Implementierung der Euro-Einführung, zur Verfügung.

- Datumsfelder sind zudem wesentlich einfacher zu identifizieren, wenn in die Analyse interne Entwicklungsmitarbeiter einbezogen sind, die die Altanwendungen kennen. Programmiersprachen wie Cobol besitzen keine spezifischen Datentypen beziehungsweise -anzeigen wie "Date" oder "Datum".

Analyse erst nach der Inventarisierung

Deshalb muß letztlich auf der Ebene von Namensmustern oder spezifischen Mustern wie "accept from date", die ein Datum vom Betriebssystem abholen, ein Datumsfeld identifiziert werden. Um diese Muster vollständig zu erfassen, sind die Erfahrungen der Mitarbeiter aus der Entwicklung und aus den Fachabteilungen nötig, die für die Programmierung und Pflege der Anwendung verantwortlich sind.

Die Analyse beginnt, nachdem der zu untersuchende Softwarebestand im Rahmen der Inventarisierung definiert ist. Dieser Gesamtbestand wird in das Analysesystem übernommen und zunächst auf Vollständigkeit überprüft. Daraus resultieren genaue Zahlen über den Umfang der umzustellenden Software.

Um präzise Informationen zu ermitteln, werden zum einen die Sourcen identifiziert, die sich aus dem Inventarbestand aussondern lassen, da sie nicht mehr nötig sind. Hierbei kann es sich beispielsweise um Unterprogramme handeln, die zwar noch im Sourcenbestand mitgepflegt, aber nicht mehr verwendet werden, da die sie betreffenden Calls im Rahmen der Programmwartung mittlerweile stillgelegt wurden.

Zum anderen finden sich all die Unterprogramme, die bekannt und in Verwendung sind, zu denen aber keine Sourcen mehr existieren. Häufig sind das Assembler-Sourcen, die als Unterprogramme fungieren und seit Jahrzehnten keine Veränderung mehr erlebt haben.

Eine weitere Funktion der Analyse besteht darin, mögliche Zerlegungen des Gesamtprojekts in handhabbare Teilprojekte aufzuzeigen. Da es bei der Analyse des Datums auf 5000 Feldern leicht zu Treffern kommen kann, ist eine solche Aufspaltung für eine praxisgerechte Projektdurchführung unumgänglich.

Erschwert wird sie allerdings dadurch, daß gerade in deutschen Rechenzentren die Softwaremodule sehr verzahnt sind. Die einzige Abhilfe versprechen hier kalkulierte Schnitte - auch wenn sich danach nicht mehr jede Verzweigung einer Datumsfunktion in einem Schritt weiterverfolgen läßt.

Die Analyse bildet einen iterativen Prozeß, der seinen Ausgang bei typischen Namenmustern oder Mustern von verwendeten Feldnamen nimmt. Viele Firmen verfügen bereits aus der Inventarisierung über Suchmusterkataloge oder setzen Data-Dictionaries wie "Data Manager" oder "Rochade" ein.

Die gefundenen Muster führen zu den "Primärkandidaten", die ein Datum beinhalten. Von ihnen ausgehend, setzt sich der Suchvorgang anhand von Arbeitshypothesen fort. Auf diese Weise lassen sich Folgekandidaten ermitteln, zu denen sie in Beziehung stehen. Das führt oft zu überraschenden Ergebnissen: Es zeigt sich, daß noch eine große Zahl zusätzlicher Datumsfelder in die Analyse einzubeziehen ist.

Den Analyseprozeß unterstützen Tools, die ein interaktives Forschen nach Mustern ermöglichen. Per Mausklick zeigen sie die Treffer, den Programmkontext und die dazugehörige Datenstruktur auf. Zum Einsatz kommen dabei zwei Werkzeugtypen: Scanner und Parser.

Scan-Tools gelangen per Dateimustersuche zunächst nur eine Ebene tief in die Anwendung. Die erzielten "Treffer" erbringen zweite Kandidaten - etwa wenn sich auf der Basis eines Datumsfeldes A ein Statement "MOVE A TO B" findet. Der Scan-Vorgang muß dann für B neu laufen. Über die Tiefe der Beziehungsbäume verlangen Scanner sehr viele Iterationsschritte. Sie setzen zudem eine saubere Protokollierung der erledigten Schritte voraus, damit nicht im Gestrüpp der Verzweigungen Datumskandidaten verlorengehen. Diesen Aufwand des manuellen Durchlaufens vieler Untersuchungsebenen verringern Parsing-Tools durch ihre automatische Erkennung von Bezügen. Sie befinden sich schon auf einem höheren Niveau maschineller "Intelligenz". Tools dieser Art lokalisieren Primärkandidaten bereits auf Basis eigener Suchalgorithmen und einer integrierten Parsing-Datenbank, die Informationen über den Sourcecode aufbaut.

Datumsfelder strahlen in andere Programme aus

Durch ihre Suchalgorithmen lösen Parsing-Tools das Problem, daß viele Datumsfelder in andere Programme oder Programmteile "ausstrahlen". Denn diese Felder übergeben ihre Inhalte - etwa durch ein MOVE, ein COMPARE oder ein RE-DEFINE - an andere und führen dort ein unentdecktes Eigenleben.

Ein guter Parser ist letztlich vergleichbar mit dem Front-end eines Compilers. Er nimmt Statements, die als Text vorliegen, auf und überführt sie zur Weiterverarbeitung in sein internes Format. Außerdem verfügt er in der Regel über semantische Informationen, die er für eine Auswirkungsanalyse nutzt.

Ein Scan-Tool ist demgegenüber für Auswirkungen blind. Beim Einsatz von Parsern stoßen Unternehmen in Deutschland zumeist auf zwei Probleme: Einerseits sind Parser fast ausschließlich für verbreitete Programmiersprachen wie Cobol, PL/1 und Assembler erhältlich. Eine Entwicklung von Parsern für "Nischen"-Sprachen rechnet sich für die Tool-Hersteller offensichtlich nicht.

Andererseits stammen fast alle gängigen Parsing-Tools aus den USA. Sie kommen deshalb mit den Eigenheiten der Entwicklungsumgebungen in deutschen Rechenzentren nicht zurecht. Auf den in den letzten 20 Jahren entstandenen Dschungel aus Entscheidungstabellen, Programmgeneratoren und Meta-Cobol-Sprachen sind sie nicht vorbereitet (siehe Kasten).

Gängige Parser verstehen den von diesen Werkzeugen erzeugten "Meta"-Code nicht. Seine Migration zu "echtem", lesbarem Cobol-85-Code wäre oft zu risikoreich: Denn irreguläre Sprachelemente würden implementiert, daneben verhalten sich die verfügbaren Konverter oft nicht stabil. Und schließlich verlagert eine Migration zu Cobol-85 das Jahrtausendproblem zunächst nur auf eine modernere Sprache, löst es aber nicht.

Rückbezug auf den Ursprungscode

Aus all diesen Gründen benötigt man Techniken, die Parser in die Lage versetzen, auch alte Sprachderivate zu verstehen. Oftmals liegt nämlich der Standard-Cobol-Code, der - ausgehend vom "Original"-Code der Spezial-Tools - über Vorübersetzer erzeugt wurde, nicht vor, weil man ihn nach der Kompilierung gelöscht hat. Zudem erschließt sich das Verständnis der Jahr-2000-Problematik nur bei der Analyse des Meta-Codes, mit dem der Entwickler vertraut ist.

Damit Standard-Parser den ursprünglichen Meta-Sourcecode in der Analyse mit berücksichtigen können, ist er zunächst erneut in den Cobol-Code zu transferieren. Dabei werden Zusatzinformationen mit übersetzt, die es beim anschließenden Parsing des Cobol-Code ermöglichen, einen direkten Rückbezug auf den für den Entwickler aussagekräftigen Ursprungscode herzustellen.

Deutsche DV-Eigenarten

In den vergangenen 20 Jahren entstand eine Vielzahl von Host-Entwicklungs-werkzeugen. Sie boten eine dritte Sprache zum Schreiben von Sourcen, die anschließend in Standard-Cobol, -PL/1 oder -Assembler vorübersetzt wurden, um von hier aus mit Standard-Compilern in Maschinencode übertragen zu werden. Zu ihnen gehören Entscheidungstabellen wie "Vorelle", das in Deutschland noch rund 100 große MVS- und BS/2000-Anwender einsetzen, sowie "Dectab". Entscheidungstabellen bieten den Vorteil, als "lesbare" Programmiersprachen sowohl Fachentscheidern als auch Programmierern verständlich zu sein.

Einen hohen Verbreitungsgrad besitzen darüber hinaus Meta-Cobol-Sprachen wie "Columbus" von Siemens-Nixdorf. Columbus erlaubt die Dokumentation der Sourcen in Form übersichtlicher und leicht verständlicher Nassi-Shneiderman-Struktogramme. Da bei der Jahr-2000-Problematik besonders die Stellen von Bedeutung sind, die Vergleiche enthalten, sind Entscheidungstabellen und Meta-Cobol für das Parsing sehr wichtig. Insbesondere der erste Teil solcher Tabellen ist voll von Entscheidungen.

Auch Sourcecode, der von Programmgeneratoren wie "Delta" und "APS" von Intersolv oder unternehmenseigenen Generatoren erzeugt wird, ist für gängige Cobol-, PL/1- und Assembler-Parser nicht lesbar. Solche Programmgeneratoren dienten dazu, Funktionen der strukturierten Programmierung einzuführen, als diese noch nicht in den Standardsprachen verfügbar waren.

Die Anpassung eines Parsers an spezialisierte Entwicklungswerkzeuge läßt sich in der Regel in wenigen Wochen verwirklichen. Denn Parser machen sich eine zentrale Eigenschaft nahezu aller Nischen-Tools zu eigen: Sie erzeugen Maschinencode erst aus einem Zwischenkompilat. Aus diesem Grund mußten die Tool-Erfinder Verfahren entwickeln, damit erkennbar bleibt, auf welche ursprüngliche Codesequenz sich eine Maschinencodesequenz bezieht. Auf diese Eigenart greifen Parser-Hersteller bei der baukastenähnlichen Anpassung ihrer Tools zurück.

Hardware-Crash

Im Hinblick auf die Inventarisierung wird vielfach übersehen, daß sich das Jahr-2000-Problem keineswegs nur auf Software beschränkt. Auch zahlreiche Hardwarekomponenten wie Plattencontroller und hardwarenahe Software würden ohne Anpassung beim Datumswechsel verrückt spielen.

Ein Beispiel hierfür ist der Datumsfehler, der herkömmlichen PCs beim Jahrtausendwechsel unterläuft: Sie springen auf den 1.1.1980 zurück. Eine Reihe an Host-Rechner angeschlossener Peripheriegeräte sind de facto als Subsysteme auf PC-Basis installiert oder verfügen über eine BIOS-ähnliche Architektur mit Echtzeituhr. Auch sie müssen in die Analyse mit einbezogen werden.

Angeklickt

Die Zeit der Inventarisierung ist angebrochen - und sei es nur, um festzustellen, welche Ausmaße das Problem 2000 haben könnte. Ein scannendes Werkzeug wird verdächtige Stellen aufspüren, verlangt aber viel Handarbeit und penible Aufmerksamkeit. Der Autor empfiehlt die Verwendung "intelligenter" Parser, warnt aber - angesichts historisch eigener Entwicklungen in deutschen DV-Umgebungen - vor allzu hohen Erwartungen gegenüber einigen Produkten. Viele in den USA verbreitete Entwicklungen reflektieren eben nur dort vertretene Softwareszenarien.

*Joachim Blome ist zuständiger Manager für Tools und Compiler bei Micro Focus in Dortmund.