Anbieter von Cobol-Entwicklungssystemen wie Acu-Cobol und Micro Focus arbeiten seit dem Jahr-2000-Boom fieberhaft an der Modernisierung der Sprache. Schon Mitte der 90er konnte man damit objektorientiert arbeiten, inzwischen funktionieren damit auch Web-Services und J2EE. Selbst die Open-Source-Community interessiert sich (ein wenig) dafür. Es gibt ein Open Cobol und Schnittstellen zu Eclipse.
Das wichtigste Argument: Gerade große Unternehmen haben über Jahrzehnte hinweg das Firmen-Know-how, mit dem sie sich gegenüber den Konkurrenten absetzen, in Cobol-Code umgesetzt. Weltweit wurden Billionen von Euro und Hunderttausende von Mannjahren in diese Programme investiert. Die Anwendungen in einer anderen Sprache neu zu schreiben käme viel zu teuer. Außerdem wäre die Gefahr groß, wertvolle Funktionen zu verlieren. Warum also sollten die Unternehmen derartige Risiken eingehen, solange die Software läuft?
Dennoch: Die große Zeit von Cobol ist vorbei. Neuentwicklungen werden damit nur in Ausnahmefällen angegangen. Wenn Blome Gartner-Group-Studien zitiert, nach denen die Zahl der in Cobol geschriebenen Anwendungen ebenso wenig sinkt wie die der Anwender, so beschreibt er Stagnation, Bestandswahrung. Das hat viel damit zu tun, dass die meisten Anwendungen in „konservativen“ Umgebungen laufen. Gemeint sind einerseits Mainframes und andererseits Anwenderunternehmen wie Banken- und Versicherungen.
Großrechner zählen wie Cobol zur Kategorie der immer wieder totgesagten Überlebenskünstler. Zwar bleiben High-End-Systeme weiterhin ein gutes Geschäft für Big Blue, doch kleinere Mainframe-Typen werden zunehmend ausgemustert und durch leistungsfähige Intel- oder AMD-Maschinen ersetzt. Finanzdienstleister, die ihre Cobol-Programme jahrzehntelang stolz als in Code gegossenes Firmen-Know-how verteidigten, beugen sich dem Kostendruck und setzen zunehmend auf preisgünstigere Standard-Software.
Neueste Kommentare
1 Kommentar zu Die sieben Leben von Cobol
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
Warum noch Cobol?
Als Programmierer mit mehr als 30 Jahren Erfahrung hauptsächlich mit Cobol stimme ich der Meinung zu, dass Service orientierte Architekturen (SOA) für Cobol ein weiteres Leben bedeuten können. Eigentlich sollte man dies nicht als neues Leben sondern mehr als Jungbrunnen bezeichnen. Da Cobol, wie gesagt eine fast natürliche Sprache ist, kann man mit Worten (Befehlen) ausdrücken, was das Programm ausführen soll. Es gibt kein Cobol++ oder Cobol# sondern einfach Cobol, zugegeben mit mehreren Spracherweiterungen aber immer noch rückwärts kompatibel. Das Konzept von Cobol wird es auch in Zukunft erlauben, diese Sprache für neue Anforderungen zu erweitern. Aus diesen Gründen entwickle ich auch heute noch neue Programme mit Cobol als der Sprache für kommerzielle Anwendungen und zwar auf und für die Windows-Umgebung.
Cobol-Anbieter wie Micro Focus bieten oft verschiedene Assistenten zur mehr oder weniger automatischen Generierung von Services aus bestehendem Code an. Ob das Resultat für die Praxis taugt, möchte ich bezweifeln, denn ein Service sollte mehr sein als ein Programm mit einem modifizierten Aufruf. Für meine unter .NET entwickelten Webservices verwende ich als Datenaustauschformat XML-Dokumente, welche ihrerseits auf .NET Datasets basieren. Mit Micro Focus Cobol for .NET können Datasets mit einfachen embedded SQL-Befehlen definiert und bearbeitet werden. Aber auch Client-Programme unter .NET können sehr gut mit Cobol entwickelt werden. Und wenn man für Winforms oder Webforms eine andere Sprache bevorzugt, ist ja gemischt sprachliche Programmierung unter .NET auch kein Problem mehr.