Betrifft CW Nr. 50 vom 16. Dezember 1994, Seite 19: "IBM will Cobol mit OO und mit grafischer Umgebung beleben"

Fuer Gurus mag OO-Cobol ein willkommenes Objekt sein, um darueber zu diskutieren. Wer aber unter Druck steht, oekonomisch wartbare Applikationen moeglichst schnell zu erstellen, sollte es nicht mit OO-Cobol probieren. Charakteristiken heutiger Applikationen sind grafische Oberflaechen und Datenbankzugriffe. Cobol bietet aber als hersteller- und Hardware-unabhaengige Sprache keine Sprachmittel fuer GUIs und relationale Datenbanken an. Das aendert sich auch nicht mit ISO 97 Cobol. Deshalb muss der Cobol-Programmierer fuer die Windows-Programmierung Fremdsysteme einsetzen, zum Beispiel Basic, C++ und Smalltalk oder darauf basierende OO- Klassenbibliotheken.

Auch die Datenhaltung wird tunlichst nicht mit Cobol- Sprachmitteln, sondern via "Embedded SQL" oder CALL-Interface angesprochen. Fuer die Programmlogik ist Cobol gut geeignet, aber hier ist das episch breite OO-Cobol eher im Nachteil. Da es in Cobol bislang keine Funktionsaufrufe gibt, fehlt die Basis, um aus Funktionen OO-Methoden herzuleiten. Die Erstellung geeigneter Klassenbibliotheken ist in OO-Cobol aber sehr aufwendig. Wer auf dem Third-party-Markt mit OO Geld verdienen will, ist gut beraten, eine kostenguenstigere und effizientere OO-Umgebung zu suchen. Wer bestehende Cobol-Programmlogik weiterentwickeln oder GUI-sieren will, braucht kein OO-Cobol, sondern effiziente Entwicklungsumgebungen und maechtige GUI-Entwicklungswerkzeuge.

Hagen Cyrus, Koeln-Deutz, via Compuserve