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.

01.11.1991 - 

Investitionssicherung macht Kombination nötig

Trotz des 4GL-Booms: Cobol läßt sich noch nicht ersetzen

Eine Sprache der vierten Generation (4GL) oder doch lieber Cobol? Für viele Anwender und Hersteller ist Cobol langst gestorben. Allerdings gibt es noch immer Argumente gegen die moderne 4GL: Eine zu enge Herstellerbindung, Spezialistentum und fehlende Sicherung der 3GL- Investitionen werden genannt. Volker Raschke

* sieht in einer 4GL, die Cobol-Programme erzeugt, die Lösung.

In einer Fachzeitung war vor einiger Zeit in der Einleitung zum Thema Vergangenheitsbewältigung folgender Satz zu lesen: " Zum Trost: Selbst bei AT&T, dem Erfinder von Unix, sollen heute noch 7000 Cobol-Programmierer wirken.. . " Wie kommt es, daß viele Fachleute, speziell die, die selbst nie ein Programm geschrieben haben, Cobol gleichsetzen mit den Hieroglyphen der alten Ägypter?Manche 4GL-Anwender zu Cobol zurückgekehrt

Seit etwa zehn Jahren wird Cobol totgesagt. Vor allem Anbieter von Sprachen der vierten Generation haben den Grabgesang angestimmt: Ihre moderne Sprache mache Cobol überflüssig, hieß es. De facto befindet sich ein Großteil dieser 4GLs längst nicht mehr am Markt während Cobol so lebendig wie eh und je ist. Inzwischen gibt es Cobol 85 (natürlich weitgehend abwärtskompatibel) und einige Werkzeuge, mit denen die Erstellung und Wartung von Cobol-Programmen mit dem Komfort von 4GLs möglich ist.

In vielen Firmen werden kommerzielle Anwendungen noch immer zu 100 Prozent in Cobol realisiert. Einige 4GL-Anwender setzen neben ihrer Sprache noch immer Cobol ein, sofern sie sich nicht darauf beschränken, kleine Zusatzauswertungen für ihre Standardsoftware zu erstellen. Manche 4GL-Anwender sind sogar wieder zu Cobol zurückgekehrt. Warum das, wenn 4GLs doch viel überschaubarer und änderungsfreundlicher sind?Keine Lösung wurde der Aufgabenstellung gerechtMitte 1987 veröffentlichte eine Fachzeitschrift einen "4GL Vergleich an einem Beispiel aus dem Berichtswesen". Einige Hersteller wurden dabei gebeten, eine bestimmte nicht-triviale Aufgabenstellung mit ihrem Werkzeug zu lösen Die Aufgabenstellung wies besonders auf das Problem hin, daß beim Vergleich zweier Dateien auch fehlende Sätze in einer der Dateien eine Ausgabe erzeugen sollen (Outer-Join).

Nachdem die etwa zehn gelieferten Lösungen oberflächlich auf ihre syntaktische und semantische Richtigkeit" werden geprüft waren, wurden sie kommentarlos veröffentlicht. Später stellte sich heraus, daß so gut wie keine Lösung dieser Aufgabenstellung - speziell dem Outer-Join-Problem - gerecht wurde. Um Mißverständnissen vorzubeugen: Auch andere Spezialisten, darunter einige 4GL Kenner, hatten enorme Schwierigkeiten herauszufinden, welche der Lösungen nicht den Anforderungen genügte.

Ein Jahr danach wurde in einem Round-table-Gespräch zum Thema "Sprachen der vierten Generation: Marketing-Trick oder Effizienzsteigerung?" auch die Frage diskutiert, warum hochqualifizierten Autoren diesen Fehler nicht bemerkt hatten. Das Ergebnis war, daß ein gewisser Black-box-Effekt durch die höhere Abstraktionsebene der 4GLs entsteht.

Im Klartext: Bei Aufgabenstellungen, die ein gewisses Maß an Komplexität überschreiten, bleibt zwar der Vorteil des geringen Erstellungsaufwands, die Analyse einer Lösung ist aber jetzt wesentlich schwieriger. Die problemlose Änderung von Anwendungen setzt sie jedoch voraus. Bisweilen ist die Modifikation schwieriger als bei einer prozeduralen Sprache - es sei denn, man hat neben der Formulierung selbst noch ein erstelltes überschaubares Cobol-Programm.

Dies ist einer der Gründe dafür, daß sich einige mutige Anwender, die ihre 4GLs wechseln wollten, von dem außerordentlich hohen Aufwand überraschen ließen. Es genügt eben nicht, die ganzen Anwendungen neu zu schreiben (wozu die Philosophie der meisten 4GLs nun einmal zwingt). Den größten Aufwand verursacht die "Programm-Archäologie", also die Analyse dessen, was die Anwendung eigentlich tut.

Soll man sich nun für Cobol oder für eine 4GL entscheiden? Richtig ist, daß die Erstellung von Cobol-Programmen mit den Methoden der 80er Jahre nicht mehr zumutbar und gefährlich ist. Personen-orientierte Programme sind häufig

Der hohe Schreibaufwand für Cobol-Formalismen verführt die Programmierer dazu, Programme aus Teilen von anderen Anwendungen zusammenzukopieren. Dabei werden Fehler und nicht benötigte Teile mit übernommen- das Programm gestaltet sich unübersichtlich. Hinzu kommt das Problem der künstlerischen Individualität. Selbst wenn Anweinsugen bestehen, Programme nacht dem normierten Programmierung ( DIN 66220 /66260)zu erstellen, selbst wenn es Konventionen für die Regeln der strukturierten Programmierung gibt (Datennamen-Vergabe etc. ), so ist es doch schwer, deren Einhaltung zu gewährleisten.

Das Ergebnis sind nur allzu häufig personenorientierte Programme, in denen sich nur die Ersteller halbwegs zurechtfindet.

Hier kommen nun die 4GL Anbieter und behaupten, mit ihren Sprachen ließen sich diese Probleme vermeiden und der Erstellungs- und Wartungsaufwand drastisch vermindern. Meistens ist etwas Wahres daran, auch wenn letztlich keine 4GL das Know-how im Software-Engineering überflüssig macht.

Trotzdem zögern viele Anwender aus guten Gründen mit dem Einsatz einer Sprache der vierten Generation: 1. Durch eine 4GL bindet sich der Anwender sehr stark an einen Hersteller. Ein Wechsel des Tools führt gewöhnlich zum Verlust aller mit dem alten Tool erstellten Anwendungen. 2. Um eine Anwendung auf eine andere Anlage zu portieren, muß dort zumindest ein Laufzeitsystem der 4GL erworben und installiert werden. 3. Das Spezialisten-Problem: Nur noch das Know-how der 4GL zählt. 4. Anwendungen können nicht teilweise, sondern nur komplett mit einer 4GL realisiert werden (was zum Teil mit Punkt 3 zusammenhängt). Ist dies nicht möglich, so muß der Anwender auf eine 3GL wie zum Beispiel Cobol zurückgreifen. Eine 4GL, die Cobol-Programme erzeugt

Cobol kann eine hochmoderne Sprache sein, wenn. man zusätzlich bestimmte Werkzeuge verwendet: Sinnvoll ist eine 4GL, die Cobol-Programme erzeugt. Außerdem sollte zusätzlich ein "Postcompiler" eingesetzt werden, der - auch für alte Cobol-Programme - die Dokumentation der Übersetzungsliste verbessert, Prüfungen auf Problembereiche wie Strukturregel-Verletzungen oder nicht angesprochene Programmteile durchführt und der zentrale Querverweis-Daten für Datenfelder, Module, Copies etc. verwaltet. Hinzu sollten Werkzeuge etwa für die Verarbeitung von Entscheidungstabellen, Verwaltung von Quellcode und die Migration von Cobol-Programmen kommen.

Beim Einsatz solcher Tools erhält der Anwender qualitativ hochwertige Cobol-Programme mit einer tiefgreifenden Normung, ohne bei der Weitergabe dieser Anwendungen oder beim Werkzeugwechsel vom Tool selbst abhängig zu sein. Anwendungen sind in Cobol gesichert, in einer Basissprache also, die zu den am weitesten verbreiteten Sprachen mit der ausgereiftesten Normung und mit einer hohen Portabilität zählt - vorausgesetzt, in dem Cobol-Programm wurde auf eine strenge Einhaltung der ANSI-Norm geachtet. Damit ist man als Cobol-Anwender den meisten 4GL-Anwendern überlegen.