Das schlechte Laufzeitverhalten der in 4GL entwickelten Applikationen beschäftigt heutzutage noch viele Hersteller und Anwender. Ein Ansatz zur Lösung dieses Problems kommt aus den Vereinigten Staaten - der Schritt zurück. Die Performance soll sich um ein Vielfaches verbessern, wenn in 4GL entwickelte Programme beim praktischen Einsatz wieder in Cobol umgesetzt werden. Für Wolfdieter Schumacher, EDV-Leiter der Berufsgenossenschaft für Gesundheits- und Wohlfahrtspflege in Hamburg, ist die Frage nach der Performance heutzutage allerdings kein Thema mehr, es gehe vielmehr um Manpower und Entwicklungskosten. Schließlich habe man sich aufgrund der Vorzüge in der Entwicklungsphase für ein 4GL-Tool entschieden, und so werde dessen Schwäche bei den meisten Unternehmen von vornherein auch akzeptiert. Den einzigen Grund, Anwendungen wieder in Cobol umzusetzen, sieht Karl-Heinz Renz, DV-Leiter der Hawera Probst in Ravensburg, darin, sich nicht in die Abhängigkeit des Softwarepartners zu stürzen: "Falls dieser nämlich in Schwierigkeiten gerät, sind unter Umständen die Investitionen in die Softwareentwicklung verloren."

Wolfdieter Schumacher

DV-Leiter, Berufsgenossenschaft für Gesundheits- und Wohlfahrtspflege, Hamburg

Von 4GL wieder zurück zu Cobol zu gehen, ist ein Schritt in die falsche Richtung. Vor knapp drei Jahren entschloß sich der Vorstand der BGW, der Empfehlung einer Unternehmensberatung zu folgen und die Realisierung eines DV-Gesamtsystems ausschließlich mit einer Sprache der vierten Generation durchführen zu lassen. Dieser Beschluß führte dazu, daß ein System von zirka 1400 Modulen neu konzipiert und realisiert wurde. Wichtig dabei war, daß neben der Realisierung der Online-Programme auch alle Batch-Programme mit einem 4GL-Tool geschrieben wurden. Einzige Ausnahme bildeten drei Cobol-Applikationen, die zur Erzeugung von Magnetbändern mit variabler Satzlänge benötigt werden.

Ein wesentlicher Vorteil dieser neu erstellten Applikationen ist deren Transparenz. Vorausgesetzt, daß bei der Entwicklung strenge Standards gesetzt werden, so daß jeder Mitarbeiter - sofern er mit der Thematik vertraut ist - auch jedes Programm lesen kann. Es besteht überhaupt kein Anlaß diese Programme wieder in einer Cobol-Umgebung zu pflegen. Außerdem setzt sich die Systementwicklung in unserem Hause hauptsächlich aus jungen Mitarbeitern zusammen, die sich nur mit hochentwickelten Sprachen beschäftigen und in bezug auf Cobol keine Bindungen haben.

Sicherlich verhält sich im Gegensatz zu Cobol ein in 4GL entwickeltes Programm hinsichtlich der Performance anders. Doch ist die Hardware heutzutage so leistungsfähig, daß sich ein eventueller Verlust der Laufzeit wieder aus gleichen läßt. Auch bemühen sich die Software-Anbieter verstärkt darum, mit weiterentwickelten 4GL-Versionen das Performance-Loch zu füllen. Vor zwei Jahren hätte die Frage nach dem Laufzeitverhalten noch ihre Berechtigung gehabt, heute nicht mehr.

Karl-Heinz Renz

Leiter Organisation und Informationsverarbeitung, Hawera Probst GmbH & Co., Ravensburg

Dem Entschluß, sich zugunsten eines Softwareentwicklungstools der vierten Generation zu entscheiden, geht normalerweise eine eingehende Untersuchung der Vor- und Nachteile voraus. Die Pluspunkte gegenüber klassischen Sprachen, wie etwa Cobol, nämlich strukturierte Methodik und die damit verbundene bessere Wartbarkeit sowie die wesentlich kürzeren Entwicklungs- und Änderungszeiten, sind nicht zu übersehen. Deshalb fallen die immer wieder ins Feld geführten Performance-Einbußen kaum ins Gewicht. Sie können durch entsprechende Hardware, insbesondere unter dem Aspekt der Preisentwicklung der vergangenen Jahre, jederzeit ausgeglichen werden. Performance ist heutzutage kein Thema mehr, vielmehr müssen die Kriterien bei der Manpower und den Entwicklungskosten gesetzt werden.

Bei der Einführung eines 4GL-Systems muß allerdings darauf geachtet werden, daß alle betroffenen Mitarbeiter eine eingehende Schulung wenn nötig auch über strukturierte Programmierung, erhalten. Und nicht das größte anstehende Projekt sollte für erste "Gehversuche" vergewaltigt werden. Wird noch die Projekt-Organisation an die Möglichkeiten eines komfortablen 4GL-Tools angepaßt, führt das zu einer erheblichen Steigerung der Akzeptanz dieses Systems, und kein Programmierer wird wohl noch lange seiner bisherigen Programmiersprache nachtrauern.

Die Entwicklung eines modular aufgebauten PPS-Systems mittels 4GL ist jetzt abgeschlossen und die sich daraus ergebenden positiven Erfahrungen werden wir in dem zur Zeit projektierten Materialwirtschafts-/Logistik-System umsetzen. Das liegt vor allem daran, daß das Verknüpfen von CICS-Transaktionen mit 4GL-Programmen aufgrund der Unabhängigkeit vom Monitor nur begrenzt möglich ist.

Die Frage nach einem "Downgrade" - Rückführung einer in 4GL entwickelten Anwendung in Cobol-Programme - ist zwar opportun, läßt sich aber mit reinen Performance-Überlegungen nur ungenügend beantworten. Und wenn schon Performance, warum dann nicht konsequenterweise gleich Assembler?

Die durch einen Cross-Compiler offerierte Möglichkeit, ein mit einem 4GL-Tool entwickeltes System portabler zu machen und die Abhängigkeit von dem Software-Hersteller zumindest theoretisch zu verringern, verlangt weitaus mehr Beachtung.

Gerhard Kehl

Abteilungsleiter Softwareplanung/-methodik, Wintershall AG, Kassel

Es wäre interessant zu erfahren, ob die Umsetzung einer 4GL-Sprache im Cobol-Code tatsächlich das Laufzeitverhalten einer Anwendung verbessern kann. Das ist sicher von der Qualität des Code-Umsetzers abhängig. Allerdings bleibt zu befürchten, daß die Umsetzung an technische Grenzen stoßen wird.

Wir haben einen 4GL-Interpreter im Einsatz; damit realisieren wir ein komplexes Anwendungssystem. Lastvergleiche mit älteren Assembler-Anwendungen zeigen eine deutlich höhere Systemlast in der 4GL-Anwendung. Das läßt sich aber auf die Tatsache zurückführen, daß in einem Entwicklungssystem der vierten Generation wesentlich höhere Anforderungen der Anwender an Komfort und Aktualität umgesetzt wurden, als dies in der älteren Assembler-Anwendung der Fall ist. Ein simpler Eins-zu-eins-Vergleich wäre hier nicht seriös.

Es ist allerdings unbestreitbar, daß ein Teil der zusätzlichen Last vom 4GL-System erzeugt wird. Der Hersteller arbeitet hier jedoch permanent an Verbesserungen. Zum Beispiel bietet das neueste Release die Möglichkeit, von der rein interpretierenden Vorgehensweise abzuweichen und bestimmte Programmteile zu binden.

Eine positive Erfahrung, die wir im Umgang mit der Sprache der vierten Generation gemacht haben, ist die Tatsache daß die Systementwicklungszeiten in den Bereichen Programmierung und Test erheblich verbessert werden - besonders bei kurzfristig zu realisierenden, überschaubaren Problemstellungen. Bei komplexen Großsystemen, die eine solide Analyse und Konzeption erfordern, wird dieser Vorteil tendentiell kleiner, außerdem bergen sie die Gefahr, daß die frühen Phasen der Entwicklung einer Trial-and-error-Philosophie geopfert werden. Davor muß ebenso deutlich gewarnt werden wie vor der Vernachlässigung der Rechnerlast-Problematik.

Die Vorteile der schnellen Systementwicklung werden also erkauft durch die Gefahr einer weniger soliden Entwicklungsarbeit und einer höheren CPU-Last der fertigen Systeme. Was tun? - Die nüchterne Abwägung der Vor- und Nachteile, die der Einsatz einer 4GL-Sprache nach sich zieht, muß von Fall zu Fall erfolgen. Eine solide Analyse der Problematik inklusive einer detaillierten Rechnerlastschätzung ist auch oder gerade beim Einsatz von 4GL-Sprachen unbedingt erforderlich.

Es ist ein Trugschluß, zu glauben, daß allein mit dem Einsatz eines leistungsfähigen Werkzeugs schon die meisten Probleme gelöst seien. Eine fundierte Abwägung dessen, was im Realtime-Betrieb notwendig und wünschenswert ist oder ohne wesentlichen Komfortverlust aus dem Dialogfenster heraus in den Nacht-Batch wandern kann, bleibt ebenfalls unumgänglich. Auch das mächtigste Werkzeug ändert nichts an der Gültigkeit einer bewährten Maxime der Systementwicklung: Ein gutes Konzept ist durch nichts zu ersetzen. Eingedenk dieses Grundsatzes bezweifle ich, ob der bloße Einsatz immer neuerer Tools, wie eines Code-Umwandlers, automatisch zu einer Lösung der dargestellten Basisproblematik führt.

Axel Bender

Leiter der Anwendungsentwicklung, Röhm GmbH, Darmstadt

Einige 4GL-Tools erzeugen einen kompakten Code, der Testergebnissen zufolge vergleichbar schnell ablauffähig sein kann wie der Maschinencode eines Cobol-Programms. Allerdings gibt es heutzutage auch Tools, die den Anspruch einer Sprache der vierten Generation nicht zu erfüllen scheinen. Je nachdem in welcher Systemumgebung man arbeitet, sind andere Grundparameter gegeben und die Tools daraufhin zu überprüfen.

Beim Einsatz von 4GL-Systemen gilt es deshalb, Prioritäten zu setzen. Eine davon ist zum Beispiel die Produktivität der Software-Entwicklung. Das Performance-Verhalten der Systeme kann diesem Gesichtspunkt untergeordnet sein. Wenn natürlich die Systemleistung als oberstes Kriterium angesetzt wird kann die Werkzeugauswahl entsprechend anders ausfallen.

Seitdem Restriktionen wie Precompiling und/oder Batch-Compiling bei den Sprachen der vierten Generation wegfallen, ist es möglich, Anwendungen interaktiv und interpretativ zu entwickeln. Der Programmieraufwand reduziert sich, die Produktivität der Software-Entwicklung steigt an.

Im Gegensatz zu Cobol können sich die Programmierer unter Verwendung eines 4GL-Tools voll um die eigentliche Aufgabenstellung kümmern und müssen sich nicht zusätzlich mit der Steuerung des Systems beschäftigen.

Ein weiterer Vorteil ist die Unabhängigkeit bei Systemumstellungen, beispielsweise von VSE auf MVS, und die Portabilität von einer Systemserie auf die andere; auch von Hersteller zu Hersteller.

Diese und andere Punkte führten zu einer großen Akzeptanz der 4GL-Technik bei den Software-Entwicklern aus unserem Hause. Ich sehe auch deshalb keinen Anlaß, die in 4GL-entwickelten Anwendungen wieder in Cobol umzusetzen.

Ingo Ladwig

Systemverantwortlicher Siemens-Anlage BS2000, Rheinische Armaturen- und Maschinenfabrik Albert Sempell KG, Korschenbroich

Die Aussage, beim Übersetzen von 4GL-Code in Cobol-Statements können Laufzeitverbesserungen um den Faktor zehn erreicht werden, ist zumindest aus unserer Sicht nicht relevant. Wenn es nur um die Performance-Verbesserung geht könnte auch Cobol auf Assembler zurückgeführt werden. Aber wer macht das schon?

Entschließt sich ein Unternehmen dafür, in der Software-Entwicklung Sprachen der vierten Generation einzusetzen, sollte es auch weiterhin auf dieser Schiene fahren. Allerdings könnten sich, falls in der Systementwicklung vorwiegend Cobol-Programmierer beschäftigt sind, Schwierigkeiten bezüglich der Akzeptanz des 4GL-Systems ergeben. Dieser alteingesessenen Mannschaft fällt es relativ schwer, eine neue Sprache zu lernen. Zudem gibt es derzeit auf dem freien Markt kaum Leute, die diese hochentwickelten Sprachen beherrschen.

Der Mangel an 4GL-Fachkräften kann so bei der Wartung in Cobol für die Majorität der Programmierer von Vorteil sein. Dieses Argument gilt jedoch nicht für unser Unternehmen, denn wir entwickeln kaum noch Software selbst sondern beziehen hauptsächlich Standardlösungen. Anpassung und Wartung übernimmt auch das jeweilige Softwarehaus. Die Programme sind im administrativen Bereich angesiedelt - also Buchhaltung, Vertrieb etc. - und in Cobol geschrieben. Ganz ohne Cobol kommt heutzutage noch kein Unternehmen aus.

Es gibt jedoch immer Bereiche, wie zum Beispiel die Qualitätssicherung, die nicht mit Standardsoftware abgedeckt werden können. Für diese Fachgebiete schreibt die Systementwicklung anhand eines 4GL-Tools noch selbst die Programme. Insgesamt sind in unserem Haus mit dieser Tätigkeit nur vier oder fünf Mitarbeiter beschäftigt, die auch die Wartung der Systeme übernehmen. Cobol ist kein Gesprächsthema mehr - wir haben uns entschlossen, auf der 4GL-Schiene zu fahren.