MS-Cobol 3.0 braucht nur 8,3 s. Die Übersetzung und Ausführung erfolgt mit
COBOL BENCH.COB; LINK BENCH IXSIO; BENCH
Der Bildschirm wird nicht automatisch gelöscht. Das Programm funktioniert anstandslos. Microfocus- und Realia-Cobol verhalten sich ebenso. Die Ausführungsgeschwindigkeit beträgt bei Microfocus 8,4 s, während Relia-Cobol nur 6,6 (!) s benötigt. Beide Compiler sind übrigens über Dongles geschützt, was sich bei Microfocus-Cobol weniger störend erweist. Realias Dongle ist unangenehm groß, was wir mit Umstecken des VGA-Adapters bezahlen mussten. Darüber hinaus ist dieser Dongle einer der Lästigkeiten, die den Drucker an der ersten parallelen Schnittstelle unbedingt Online geschaltet wissen wollen und sich außerdem nicht mit anderen Dongles, beispielsweise mit dem von Microfocus vertragen.
MS-Cobol 3.0 und Microfocus-Cobol sind übrigens nahezu 100 Prozent kompatibel. Anstatt IXSIO, verlangt jedoch Microfocus beim Binden mit LINK die Bibliothek EXTFX. Realia-Cobol-Programme werden mit den Eingaben
REALCOB BENCH LINK BENCH,,,REALCOB BENCH
übersetzt und ausgeführt.
Acu-Cobol benötigt genau wie MS-Cobol 2.1 die ASSIGN TO DISK-Klausel. Anstatt VALUE OF FILE-ID akzeptiert Acu-Cobol jedoch nur VALUE OF LABEL. Die Ausführungsgeschwindigkeit beträgt 29,8 s. Der Bildschirm wird nicht automatisch gelöscht.
MBP verlangt zur Übersetzung und Ausführung von Cobol-Programmen die Eingaben
VISCOB BENCH LINK VCMAIN BENCH,BENCH,NUL,VCOBOL+VCSORT+VCISAM; BENCH
Der Bildschirm wird nicht gelöscht. Die ACCEPT-Anweisung erzeugt automatisch ein akustisches Signal. BENCH wird zunächst in 12,5 s abgearbeitet. Allerdings gibt es mit der Sinus-Berechnung Schwierigkeiten. Näheres hierzu im Kasten. Nach der Korrektur benötigt BENCH 22,8 s.
RM-Cobol-Programme werden mit den Eingaben
RMCOBOL BENCH RUNCOBOL BENCH
übersetzt und gestartet. Nach 14,5 s kommt unser Benchmark-Programm zum Schluss. Etwas störend ist die anschließende Ende-Meldung, die den Bildschirm zwangsläufig nach oben rollen lässt.
Probleme bereiten grundsätzlich ACCEPT- und DISPLAY-Anweisungen. Weil sie nur geringfügig standardisiert sind, gehen sämtliche Compiler-Hersteller eigene Wege, ACCEPT und DISPLAY mit zusätzlichen Attributen zu versorgen. Beispielsweise stößt die direkte Platzierung des Cursors über Variablen mit den gewünschten Koordinaten auf die haarsträubendsten Schwierigkeiten, die sich kaum nachvollziehen lassen. Hier helfen nur genaue Beobachtungen, wie sich das Programm verhält und trickreiche Veränderungen.
Schauen Sie sich dazu unsere Listings in auf den Seiten … an. Bei genauem Hinsehen werden Sie nur schwer erklärbare Unterschiede feststellen. SHOW.COB soll für jeden Compiler haargenau dieselbe Bildschirmmaske erzeugen. Und konkret das ist das Problem. Damit sich die Programmlänge in Grenzen hält, haben wir auf Farbattribute verzichtet. Aufgrund der Unterschiede in der Ausführungsgeschwindigkeit sind auch Abweichungen in eigenen Pause-Funktionen zu erwarten.
Als professioneller Programmierer, der Cobol-Programme häufig portieren muss, sollten Sie deshalb auf mit herstellereigenen Attributen kombinierte ACCEPT- und DISPLAY-Anweisungen verzichten und grundsätzlich die CALL-Schnittstelle verwenden. Hier bieten die Compiler-Hersteller nämlich äußerst individuelle Programmiermöglichkeiten – die meist sehr komfortablen Bildschirmroutinen bleiben dadurch lokal und lassen sich unabhängig vom übrigen Programm in einem Rutsch anpassen.
Achtung! Bug in MBP’s Visual-Cobol!
Wir haben für den in dieser Ausgabe beschriebenen Test ein kurzes Benchmark-Programm geschrieben, das u.a. mit Hilfe der vier Grundrechenarten und Potenzierung den Sinus einer gebrochenen Zahl von -3,14 bis +3,14 berechnet. Während die Routine auf allen Cobol-Compilern mit geringfügigen Änderungen funktioniert, errechnet Visual-Cobol grundsätzlich den Wert 0. Laut MBP „…hängt das festgestellte Problem mit mathematischen Einschränkungen der Potenzierungs-Operationen im Raum der reellen Zahlen zusammen. Unsere Exponent-Funktion ist in der Lage, gebrochene Exponenten auszuwerten. Dieser Algorithmus ist bei negativer Basis nicht anwendbar. Wir haben im Laufzeitsystem eine Abfrage implementiert, die bei ganzzahligen, positiven Exponenten einen anderen Algrorithmus verwendet…“. MBP stellte uns eine korrigierte Bibliothek zur Verfügung, mit der wir unser Benchmark-Programm neu binden mussten. BENCH funktioniert nun einwandfrei.
💡 Sie haben einen Linkedin-Account? Dann können Sie meinen Newsletter „Der 18-Jährige, der einen Zettel schrieb und verschwand“ abonnieren ✔︎