"Am Anfang war das Nichts."Als der Apple II-PC in den Markt einschlug, gab es nur einen einfachen Basic-Interpreter und einen Assembler für die Programmentwicklung. Sogar als Big Blue den IBM-PC ein paar Jahre später herausbrachte, waren nur Basic-Interpreter, Assembler und Pascal-Compiler verfügbar. Als die Marktbedürfnisse wuchsen und die Leistungsfähigkeit der PCs stieg, kamen Cobol und auch C als verfügbare Programmiersprachen hinzu.
Zunächst jedoch wurden fast alle Entwicklungen in Basic-Interpreter, Assembler und Pascal-Compiler geschrieben. Das Programmangebot beschränkte sich damals noch auf Softwarepakete wie Textverarbeitung, Tabellenkalkulationen und Hilfsprogramme. Es gab auch einige Entwicklungen für kleine Buchhaltungssysteme und Dateiverwaltungssysteme, wie Dbase. Doch die Zahl der Programmentwickler war gering im Verhältnis zu der Menge der PC-Anwender.
PC ist nicht länger ein Superschreibsystem
Als die Marktbedürfnisse wuchsen, und die Leistungsfähigkeit der PCs stieg, kamen Cohol und auch C als verfügbare Programmiersprachen hinzu. In den ersten acht Jahren der PC-Entwicklung arbeiteten hauptsächlich Systemprogrammierer an der Herstellung spezieller Softwarepakete.
Seit 1987 etwa hat sich das Gewicht der Benutzung der PCs dramatisch verlagert. Der PC ist nicht länger das Superschreibsystem oder der Superkalkulator oder das Superdateisystem, der er vorher gewesen ist. Der PC ist nun ein hochgradig integriertes Datenendgerät im Kommunikations- und Informations-Netzwerk der Großunternehmen. Verbunden mit dem Rollenwechsel des PCs ist die explosionsartige Verbreitung von CASE-Tools. Das war der Grund, weshalb PCs von nun an auf den Schreibtisch einesjeden Programmierers rückten. Jetzt muß der Programmierer seinen PC für folgende drei Dinge nutzen:
- als Arbeitsstation für innerbetriebliche Aufgaben (Zeitplanung, Electronic Mail);
- als Entwicklungsplattform für andere Systeme;
- als Entwicklungsmaschine für PC-Systeme.
Sowohl die CASE-Tools, die jetzt verfügbar sind, als auch die demnächst verfügbaren werden zwar auf PCs installiert, jedoch die Zielmaschinen für die entwickelten Systeme sind der PC und auch der Großrechner. In der Tat ist die Designphase in weiten Teilen - unabhängig von dem Zielsystem. Diese Entwicklungswerkzeuge sorgen für eine mächtige Plattform, die den Programmierer in die Lage versetzt, große Anwendersysteme zu entwickeln, wie er sich das vor fünf Jahren nicht hätte träumen lassen.
Welche Programmiersprache sollte dieser Programmierer benutzen? Sollte es Cobol sein, altbekannt und vertraut, oder besser C, der Newcomer auf dem Markt? Beide Sprachen können für die Erstellung eines Programms mit beliebigen Anforderungen benutzt werden. Es gibt nur wenige Situationen, wo C (oder Assembler) bevorzugt eingesetzt werden sollte. Das gleiche gilt aber auch für Cobol. Cobol ist eine kommerziell orientierte Programmiersprache. Der jetzt gültige Standard (ANSI '85) stellt mächtige Sprachelemente mit wenigen Einschränkungen für effektives Programmieren zur Verfügung. C dagegen ist eine systemorientierte Sprache. C erlaubt die schnelle Entwicklung einfacher Hilfsprogramme, ist aber auch vollständig genug, die Entwicklung kompletter Betriebssysteme, wie zum Beispiel Windows 3.0 oder OS/2, zu unterstützen.
Es gibt viele gute Gründe für die Benutzung von Cobol:
-eine große Benutzer-Gemeinde,
- ein Fundus bestehender Programme,
- Entwicklung für viele Zielsysteme,
- kommerziell orientierte Sprache,
- schnelle Ubersetzungs- und Ausführungszeit.
Ad 1: Obwohl die Schätzungen, die Zahl der aktiven Cobol-Programmierer betreffend, differieren, gibt es zirka zwei Millionen Cobol-Programmierer in Nordamerika. Und die Zahl wird wegen dauernder Nachfrage ständig größer. Dieser Reichtum an Erfahrung sollte keinesfall vergeudet oder ignoriert werden. Die Cobol-Programmierer haben das Wissen über kommerzielle Anwendungspakete - ein unschätzbarer Wert für die Entwicklung neuer Systeme. Sie sollten darin bestärkt werden, neue Anwendungen mit neuen Werkzeugen zu entwickeln, die auf dem PC verfügbar sind. Es ist ineffektiv, die Zeit mit dem Erlernen neuer Programmiersprachen zu verbringen, die die Produktivität oder die Fähigkeiten der Zielsysteme nicht verbessern.
Ad 2: Die Zahl der in Cobol geschriebenen Code-Zeilen wird auf mehrere Milliarden geschätzt. Dieser Code kann nicht ersetzt oder schnell neu entwikkelt werden. Zum Beispiel werden 90 Prozent aller Lohn- und Gehaltsüberweisungen von Cobol-Prograrnmen gesteuert. Wer will sich damit anlegen?
Ad 3: Es gibt zwar hier und da einen Versuch, Programmiersprachen zu entwickeln, die portabel zwischen Betriebssystemen sind. Cobol ist die einzige Programmiersprache, die auf allen kommerziellen IBM-Systemen einschließlich PS/2, AS/400 und /370 unterstützt wird. Die einzige andere Programmiersprache, die eine weite Verbreitung auf IBM-Plattform hat, ist RPG (zur Zeit nicht auf PS/2 verfügbar). Obwohl IBM kürzlich einen C/370-Compiler herausgebracht hat, verfügt C innerhalb der IBM-Welt nicht über die Entwicklungsumgebung für andere Zielsysteme.
Ad 4: Cobol ist keine alte, sondern eine ausgereifte Sprache. Cobol wird seit Ende 1950 kommerziell genutzt. Das heißt, Cobol hat mindestens 30 Jahre lang Zeit gehabt, sich zu entwikkeln und zu wachsen. Cobol von heute ist nicht mehr die schwierige Sprache der 70er Jahre. Der heutige Programmierer muß nicht mehr mit der Sprache kämpfen wie vielleicht früher. Alle Konventionen der strukturierten Programmierung werden vom Sprachstandard direkt unterstützt. In Kürze wird ein objektorientierter Cobol-Standard von Codasyl veröffentlicht. Es gibt nur wenige Aufgabenstellungen, die nicht in Cobol gelöst werden können. Zum Beispiel sind die Cobol-Compiler meist selbst in Cobol geschrieben. Auch so systemnahe Programmsysteme wie Real CICS sind vollständig in Cobol geschrieben.
Sprochelemente von Cobol und C
Ich möchte gerne die Sprachelemente von Cobol mit C vergleichen. Fürsprecher von Cobol behaupten, die Überlegenheit von C läge in der Flexibilität und der Möglichkeit der Programmierer, die Sprache schnell und einfach zu erweitern. Das aber erlaubt nicht nur jedem Programmierer, "sein" C zu individualisieren, sondern verlangt von jedem Programmierer beziehungsweise von jedem Entwicklungsteam spezialisierte Routinen zu bauen oder einzukaufen, um gängige Funktionen durchzufahren, die nicht in der Sprache vorgesehen sind. Diese Funktionen sind unter dem Namen "Toolboxes" oder "Libraries" bekannt. Ein erfahrener Manager einer Entwicklungstruppe würde dieses Konzept als private Spracherweiterung bezeichnen. Da gibt es eine Extradokumentation und zusätzlichen Trainingsaufwand, verbunden mit der Pflege dieser Routinen. Mit diesen privaten Toolboxes sind die Programmierer nicht mehr portabel. Jeder neue Programmierer in einem Team muß die dort vorhandenen Toolboxes lernen und möchte auch seine alten von seinem letzten Job oder von seinem letzten Team mit einbringen. Daher wachsen diese Toolboxes ungemein.
Funktionen von Cobol, die nicht in C verfügbar sind:
Formatierte Ausgabe ist in C direkt nicht möglich, zum Beispiel ZZ.ZZZ.ZZ9,99-.
Spezielle Formatroutinen müssen entwickelt werden, um diese einfachen Formatierungsregeln zu unterstützen.
Es fehlt die Möglichkeit von "sort".
Indexsequentielle Dateisysteme müssen von Drittanbietern gekauft werden, und hiermit muß die Unterstützung eines weiteren Lieferanten gesichert werden.
Die Übertragung von Daten aus einer Variable in eine andere mit einer anderen Länge ist nicht in der Sprache impliziert, und es muß spezieller Code entwickelt werden, um zu bestimmen, welches Feld kleiner ist, und zusätzlicher Code zum Abschneiden oder Auffüllen von Nullwerten muß generiert werden.
Cobol-Progromm leichter zu verstehen
Einfache kaufmännische Arithmetik wie zum Beispiel Prozentrechnen ist bei C nicht verfügbar. Rechnet man mit Nachkomrnastellen bei C, so wird intern in Gleitkomma gerechnet. Da man keinen Einfluß auf die Normalisierung hat, ist das Rechenergebnis bei C nicht vorhersehbar. Bei Cobol kann der Programmierer durch die Picture-Klausel die interne Arbeitsweise bestimmen und das exakte Ergebnis vorhersagen.
Ich bin der subjektiven Meinung, daß ich ein Cobol-Programm leichter verstehen kann als ein C-Programm.
Es gibt natürlich auch Eigenschaften von C, die man bei Cobol vermißt. C hat einen Preprozessor, der ein bedingtes Compilieren erlaubt. Auch die Verwendung symbolischer Litterale (.. DEFINED AS ..0) ist in C sehr gut gelöst. Die Verwendung von CASE-Werkzeugen nivelliert jedoch diesen Vorteil.
C unterstützt Funktionsaufrufe, Cobol dagegen nur Unterprogrammaufrufe. Bei C ist die Sprachkonstruktion "IF Bedingung..", wenn Bedingung einen Funktionsaufruf mit einem Rückgabewert enthält, besonders komfortabel. Das Codasyl Cobol Committee hat im Journal Of Development 1988 eine umfangreiche Liste von Funktionen veröffentlicht, die in Cobol integriert werden sollen. Hierzu gehört Sinus, Cosinus, Tangens, Logarithmus etc. Außerdem finden sich hier Funktionsaufrufe zum Konvertieren von Datum, Uhrzeit etc.
C ist in bezug auf Objektorientierung sehr viel weiter fortgeschritten. Ein Vorschlag für OOP-Cobol ist von Codasyl im Dezember 1990 beschlossen worden.
Übersetzungs- und Ausführungszeiten sind entscheidende Faktoren bei kommerziellen Projekten. Gerade bei interaktiver Bearbeitung bestimmt die mittlere Antwortzeit die Zufriedenheit der Anwender. Ist das Antwortzeitverhalten unzureichend, so müssen die Programmierer zusätzliche Zeit für Optimierungen aufwenden, oder die Hardware muß mehr oder weniger kostspielig erweitert werden. Übersetzungs- und Ausführungszeiten sind auch verantwortlich für die Zahl der durchführbaren Testläufe, und somit werden hierdurch die Qualität der Anwendersoftware und die Projektdauer bestimmt. Man kann zwar eine Problemlösung kürzer in C als in Cobol formulieren. Die Programmerfassung ist aber für die Dauer eines Projekts unerheblich. Stellt man noch Anforderungen an die Lesbarkeit, so dürfte ein Cobol-Programm sogar kürzer sein.
Um die Zeiten vergleichen zu können, habe ich ein Benchmark-Programm in C umgeschrieben. Dieses Benchmark-Programm ist ursprünglich erstellt worden, um einen Laufzeitvergleich auf PC zwischen
Realia Cobol und anderen Cobol-Compilern zu ermöglichen. Da Sortierung und indexsequentielle Verarbeitung bei C nicht definiert sind, sind diese Funktionen ausgelassen worden. Als ich die Benchmark-Version von C entwickelte, bin ich davon ausgegangen, daß Cobol und C ein ähnliches Laufzeitverhalten haben. Um so überraschter war ich, daß Cobol mit Ausnahme des bekannten "Sieve of Erastosthenes" (Ermittlung der ersten Primzahlen) C in den Schatten stellte. Wenn man bedenkt, daß Primzahlermittlung keine primäre kommerzielle Anwendung ist, ist Cobol in allen kommerziellen Grundelementen besser als C. Auch die Übersetzungsarbeit war bei Cobol doppelt so gut. Obwohl ich schon einen Ratfor-Compiler (Vorläufer von C) implementiert habe, kann ich meine 22jährige Erfahrung mit Cobol nicht leugnen. Eingedenk des EDV-Spruchs "Traue keinem Benchmark-Test, den du nicht selbst gefälscht hast", stelle ich Quell- und Ausführungscode jedem Interessenten unentgeltlich zur Verfügung. Die Beispiele sind so gewählt, daß sie mit jedem Cobol- und C-Compiler übersetzt und ausgeführt werden können. Das Benchmark-Programm ist in 25 Einzeltests gegliedert, die verschieden oftiteriert werden, um in angemessener Zeit eine hinreichende Genauigkeit zu erzielen. Mit der Veränderung der Iterationen kann jeder die Tests für sein Benutzerprofil anpassen.