Immer mehr Anwender benutzen für Datei- und Datenbankauswertungen moderne Abfragesprachen: Load-and-Go-Systeme, bei denen Umwandlungen und Linkläufe nicht mehr nötig sind und die schon deshalb einen Zeitvorteil gegenüber "klassischen" Compilern haben.
Zur Entlastung der Programmierung und für die zum Teil erhebliche Steigerung der Effizienz in der kommerziellen Datenverarbeitung wurden in den letzten Jahren außer allgemeinen Programmier- und Testhilfen sowie Programm-Generatoren Werkzeuge entwickelt, die man insgesamt als Formuliersprachen bezeichnen kann. Sie haben gemeinsam, daß sie alle im Load-and-Go-Modus, daß heißt, ohne Umwandlungen und Bindeläufe (Linken) arbeiten und wo sie einmal vorhanden sind, ebensowenig wegzudenken sind wie bequeme Schnellstraßen, an die man sich rasch gewöhnt hat.
Das gilt für die US-Produkte "Culprit" (ADV/ORGA), "Data Analyzer" (Roland Berger) und "Easytreave" (Pansophic) ebenso wie für das in Deutschland entwickelte "Siros" von der Ton Beller GmbH, Bensheim.
Wie wenig man aber heute noch über die in Leistungsumfang und Mächtigkeit unterschiedlich zu beurteilenden neuen Sprachen weiß, zeigt auch die relativ willkürliche Zuordnung zu drei Abschnitten des "ISIS Software Reports" unter insgesamt sechs Hauptdeskriptoren (von Datenbankauswertung bis Printprogramme).
Merkmale der Abfragesprachen
Was ist typisch für diese Gruppe von Sprachen, die so unauffällig entstanden, daß man schon eher von einer Evolution (statt Revolution) sprechen kann? Wie konnten sie sich in nicht gerade unbedeutenden Bereichen der EDV-Anwendung gegen Cobol, PL/1 oder Pascal durchsetzen und wieso lassen sie das Umdenken auf konventionelle Programm-Generatoren oder neue Sprachen wie ADA oder C nicht mehr ganz so attraktiv erscheinen? Wir untersuchten die Gründe bei Siros, hier einige wichtige Merkmale dieses Compilers:
- Strukturen von Dateien und Datenbanken werden nur einmal in "Adreßtafeln" abgebildet und bei jedem späteren Bedarf ohne weiteres Zutun des Anwenders automatisch zur Verfügung gestellt. Es handelt sich um eine pragmatische Lösung, wie sie mit ähnlich weitgehender Konsequenz bisher nur bei Mark IV oder durch IBM beim System /38 realisiert wurde.
- Die nicht-prozedurale Sprache orientiert sich an einer einfachen Struktur (als Wurzelsegment, Abbildung 1). Nur die jeweils benötigten Funktionen werden durch Schlüsselwörter aufgerufen. Die Eingabe ist formatfrei.
- Die Siros-Sprache orientiert sich an der natürlichen Sprache des Anwenders (Original-Version Deutsch, andere Sprachen generierbar). Dadurch werden logisches und formales Umsetzen wesentlich erleichtert (Beispiel einer Siros-Abfrage, Abbildung 2); praktisch dokumentiert sich die Lösung selbst. Starke relationale Merkmale - mindestens vergleichbar mit APL und SQL von IBM - sowie die generelle Mächtigkeit der Sprache erlauben stufenweise Entwicklung ebenso wie komplexe Lösungen bei einem Minimum an Schreib- beziehungsweise Codieraufwand.
- Nach Syntax-Prüfung werden sofort ablauffähige Programme in Maschinencode generiert und durchgeführt (Abbildung 3). Dadurch extreme Verkürzung von Entwicklungs- und Testzeiten.
- Anders als die nicht besonders laufzeitgünstigen Interpreter-Systeme liegen Einphasen-Compiler wie Siros mit ihrer Performance durchweg bei guten Assembler-Zeiten, das heißt um den Faktor 1,2 bis 3,5 (!) günstiger als Cobol oder PL/1. Deshalb wohl auch die zunehmende Tendenz beim Einsatz der Formuliersprache für laufende oder wiederkehrende Produktionsaufgaben.
Insgesamt werden im Eingabebereich alle derzeit verbreiteten Organisationsformen unterstützt (DL/1 sowie alle drei Arten VSAM mit Alternate Index), mehrfach ansprechbare Schnittstellen erlauben die Verknüpfung mit Benutzer-Programmen. Es gibt "aus Sicherheitsgründen" bei Anwendung in Fachbereichen - keinen Update, jedoch können gleichzeitig mit einer Vielzahl von Listen auch unterschiedliche neue Dateien ausgegeben werden. Immerhin reicht das bei einer Vielzahl von Anwendern aus, um über 50 Prozent aller anfallenden kommerziellen Aufgaben mit Siros zu lösen.
Interessant ist nun der folgende Vergleich, bei dem Cobol als Repräsentant der am meistem verbreiteten konventionellen höheren Programmiersprachen der Formuliersprache Siros gegenübergestellt wird.
Wenn man davon ausgeht, daß das logische Durchdringen einer Aufgabe bei beiden Sprachen gleichviel Raum einnimmt, wäre mit dem logischen Umsetzen zu beginnen: Bereits hier zeigen sich wesentliche Vorteile der in unmittelbarer Nähe unserer Umgangssprache angesiedelten Formuliersprache - oder: Die Sprache, in der sich unser Denken vollzieht, braucht nicht erst "übersetzt" zu werden, zumal man einer vorgegebenen einfachen logischen Struktur quasi wie einem "Fahrplan" folgen kann.
Während die Vorteile einer Formuliersprache beim logischen Umsetzen kaum quantifizierbar sind, ist das beim formalen Umsetzen, das heißt bei der eigentlichen Steuerung und datentechnischen Verarbeitung, deutlich erkennbar: In vielen Fällen wird bei Siros weniger als zehn Prozent des bei Cobol erforderlichen Zeitaufwandes anfallen. Bei der jeweils erforderlichen Anzahl von Befehlen oder Codierzeilen sieht es ähnlich aus.
Dort wird auch deutlich, daß bis zur ersten produktiven Verarbeitung bei der Formuliersprache einfach weniger Stufen zu durchlaufen sind. Anstelle von Umwandlungen erfolgen lediglich Syntax-Prüfungen die im Sekundenbereich liegen. Linkläufe entfallen völlig, und die Generierung eines Programmes in Maschinensprache ist mit unter einer Sekunde Dauer auch noch schneller als allein das Hereinholen eines Programms aus einer Bibliothek.
Die erwähnten gelten noch einmal in vollem Umfang beim Testbetrieb, bei Wartung und Pflege. In Zeitdauer eines Projekts verkürzt sich spürbar, oft auf weniger als zehn Prozent der bisher benötigten Zeit. Schließlich können sich auch Maschinenlaufzeiten verkürzen, wie Abbildung 4 Zeigt.
Gute Leute sollten mehr denken dürfen
Qualifizierte Programmierer, die sich bisher über einen zu geringen Anteil kreativer Arbeit beklagten, gewinnen schnell ein positives Verhältnis zur Formuliersprache. Es "motiviert", wenn man insgesamt mehr denken darf und weniger schreiben (oder tasten) oder Formalfehler korrigieren muß (Abbildung 5). Auch unter betriebswirtschaftlichen Gesichtspunkten verdient man dann eher, was man verdient.
Es macht Spaß, wenn man einen überraschend angeforderten Bericht oft schon nach wenigen Minuten vorlegen kann. Oder wenn man - ohne Hast und Hetze - eine bei Cobol mit einer Woche veranschlagte Aufgabe schon nach einem Tag abschließen kann. Dann überrascht auch nicht mehr die durchweg positive Auswirkung der neuen Situation auf den internen Stellenwert (sprich "das Ansehen") der Datenverarbeitung.
Bei Überlegungen zur Verbesserung des Berichtswesens sollten Alternativen nicht nur bei weiteren (konventionellen) höheren Programmiersprachen, dorthin orientierten Programm-Generatoren oder Dokumentations-Systemen gesucht werden, sondern auch bei den inzwischen zu überlegener Leistung "herangereiften" modernen Formuliersprachen. Man wird an diesen Compilern nicht mehr ganz vorbeikommen, besonders wenn sie auch noch erweiterte Online-Möglichkeiten bieten.
AU:Dr. Heinz Treßer und Friedrich Hirschfeld*