Foto: Everett Collection - shutterstock.com
Die 60 Jahre alte Programmiersprache ist eine Institution: Riesige COBOL-Anwendungen sind weltweit immer noch im Einsatz - viele davon laufen wie am ersten Tag. Die Common Business Oriented Language (COBOL) ist offenbar nicht tot zu kriegen und wird wohl auch auf absehbare Zeit sehr lebendig bleiben. Inzwischen sind viele Unternehmen sogar wieder auf der Suche nach COBOL-Experten, um alte Programme anzupassen und ihre Legacy-Applikationen in die Cloud zu überführen.
COBOL - Definition & Geschichte
Fragen Sie mal einen durchschnittlichen Softwareentwickler nach Common Business Oriented Language (COBOL), er wird Sie anschauen, als hätten sie gerade nach verbleitem Benzin oder einer Floppy-Disc gefragt. Verglichen mit modernen Programmiersprachen wie Go oder Python - und sogar solchen wie Pascal oder C! - wirkt COBOL wie aus der Zeit gefallen: schwerfällig, plump und überfrachtet.
Erfunden wurde COBOL in den späten 1950er Jahren. Die Entwicklung der Programmiersprache wurde vom Verteidigungsministerium der Vereinigten Staaten und einem Konsortium großer Computerhersteller (unter anderem IBM, Honeywell, Sperry Rand, Burroughs) angeschoben und finanziert. Das Ziel war die Kreation einer Coding-Sprache, die folgende Attribute mitbringen sollte:
Interoperabilität zwischen Computersystemen, damit Software sowohl generationen- als auch herstellerübergreifend migriert werden kann;
eine wesentlich stärkere Orientierung an der natürlichen (englischen) Sprache, als andere Programmiersprachen dieser Zeit (zum Beispiel Fortran), um eine breite, nicht unbedingt technisch orientierte Zielgruppe mit Codieraufgaben betreuen zu können, auch wenn darunter die Betriebsgeschwindigkeit leiden würde;
die Möglichkeit, zukünftige Änderungen schnell vornehmen zu können.
Die ersten offiziellen COBOL-Spezifikationen wurden im Jahr 1960 herausgegeben. Im Laufe der nächsten zehn Jahre entwickelte sich COBOL - zum Ärger manchen IT-Professionals - zum neuen Standard für Business-Applikationen. Ein Grund für die rasante Verbreitung der Programmiersprache lag darin, dass IBM ein aggressiver Early Adopter von COBOL war. Die damalige Marktmacht von Big Blue befeuerte den COBOL-Einsatz im Business-Umfeld erheblich.
Wegen ihrer Design-Vorteile und ihrem Verbreitungsgrad hat COBOL die Systeme, für die die Sprache ursprünglich entworfen wurde, um Jahrzehnte überlebt. Schätzungen zufolge war COBOL im Jahr 1970 die meistgenutzte Programmiersprache der Welt. Im Jahr 1997 sollen 80 Prozent aller Business-Applikationen COBOL-Anwendungen gewesen sein.
COBOL - die Programmiersprache
Die Urheber verfolgten das Ziel, eine Programmiersprache zu etablieren, die auch von Nicht-Developern gelesen und verstanden werden konnte. Deswegen brachen sie mit der bis dahin bei der Codierung vorherrschenden, prägnanten Syntax. Ein "Hello world"-Programm in frühem COBOL-Dialekt sieht folgendermaßen aus:
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO-WORLD.
PROCEDURE DIVISION.
DISPLAY 'Hello World!'.
END-DISPLAY.
STOP RUN.
Aus der Perspektive von modernen Softwareentwicklern, die an Python und Co. gewohnt sind, ist dieser Code völlig überfrachtet. Dabei hat die vermeintliche Langatmigkeit von COBOL einen guten Grund: Der Code wird wesentlich öfter gelesen als geschrieben, weswegen er vor allem mit Blick auf die Lesbarkeit geschrieben werden sollte.
Das gleiche Programm in einer etwas modernen COBOL-Version würde in etwa wie folgt aussehen:
program-id. hello.
PROCEDURE DIVISION.
display "Hello world!".
stop run.
Dieses Beispiel ist schon wesentlich prägnanter, allerdings kommt dasselbe Prinzip zur Anwendung: Der Code versucht die Vorgänge bei jedem einzelnen Schritt so exakt wie möglich zu beschreiben.
Geht es um die Syntax und die interne Organisation von Programmen, weist COBOL strikte Regularien auf. Dabei wird ein Programm in verschiedene Sektionen oder "divisions" aufgeteilt, um die einzelnen Komponenten besser im Blick zu behalten und verstehen zu können:
Die Identification Division ist im Grunde der Platz für Metadaten, also beispielsweise Details zum Programm und seinem Autor.
Die Environment Division enthält Details über die Laufzeitumgebung - beispielsweise Aliase für externe Devices, die unter Umständen geändert werden müssen, wenn das Programm auf anderer Hardware läuft. Diese Sektion trägt auch zur Portabilität zwischen Systemen bei, etwa wenn Ein- und Ausgabe völlig unterschiedlich gehandhabt werden.
Die Data Division enthält die Sektionen "Datei" und "Arbeitsspeicher" und beschreibt die Dateien und Variablen, die im Programm verwendet werden.
In der Procedure Division "lebt" der Programmcode - aufgedröselt in logische Einheiten ("Sections", "Paragraphs", "Sentences" und "Statements")
Darüber hinaus weist COBOL strikte Formatierungsregeln für den Code auf - bis hin zur Anzahl von Leerzeichen vor einem Befehl. Einige dieser Restriktionen sind ein Beiprodukt der Mainframe-Ära der 1960er Jahre: Damals wurden Programme mit Lochkarten codiert - die exakte Formatierung von 80 Spaltenpositionen machte eine exakte Formatierung unabdingbar.
Die Idee hinter den strikten Regularien: COBOL-Programme sollten sich so weit wie möglich selbst dokumentieren. Schließlich würden die Applikationen über Jahrzehnte im Einsatz bleiben. Nur so konnte ein Programmierer ohne vorherige Absprache direkt dort anknüpfen, wo sein Vorgänger aufgehört hatte.
- Produkt- & Projektmanager
Ganz generell schätzen es Entwickler nicht so besonders, wenn ihnen jemand erklären will, wie sie ihren Job zu machen haben. Weil Produkt- und Projektmanager aber oft Entwickler-Teams leiten, passiert genau das. Das kann zu Unstimmigkeiten führen. <br /><br /> Dazu hat auch David Fox von devRant eine Meinung: "Letztendlich ist es in den meisten Fällen so, dass Produkt- und Projektmanager in irgendeiner Art und Weise die 'Besitzer' von Projekten und Prozessen sind, ohne dabei die täglichen Herausforderungen und Probleme der Softwareentwickler zu kennen." - Chefs
Genau wie die Produkt- und Projektmanager sind auch Development oder Engineering Manager dafür zuständig, Teams von Entwicklern zu führen und sicherzustellen, dass Projekte rechtzeitig und unter Budget fertiggestellt werden. <br /><br /> "In einigen Unternehmen können Situationen entstehen, in denen der Chef gleichzeitig Mitglied des Entwicklerteams ist. Insbesondere wenn der Chef vorher selbst Entwickler war und nach einer Beförderung zum Chef wird, ist Konfliktpotenzial gegeben", merkt Fox an. - Recruiter
Softwareentwickler müssen gar nicht selbst aktiv nach einem Job suchen, um von Recruitern und Headhuntern belästigt zu werden - dem Fachkräftemangel sei Dank. Es dürfte sehr schwer sein, einen Developer zu finden, der noch nicht in die Fänge der Recruiter geraten ist. <br /><br /> David Fox sieht insbesondere die Hartnäckigkeit der Recruiter als Problem: "Sie rufen an, sie e-mailen und sie lassen Dich einfach nicht in Ruhe - selbst dann, wenn Du gar keinen Job suchst. Und selbst wenn man eine Anstellung sucht, neigen viele Recruiter dazu, irrelevante Jobangebote zu machen oder Stellen zu empfehlen, deren Profil überhaupt nicht passt - etwa einen Job am anderen Ende des Landes, obwohl man gar nicht bereit ist, umzuziehen." - Dokumentation
Gibt es keine Dokumentation, beschweren sich die Softwareentwickler. Wenn es zuviel ist, beschweren sie sich und wenn sie die Dokumentation selbst erledigen müssen, auch. Sogar über die Art und Weise, wie andere Leute die Dokumentationsaufgabe bewältigen, beschweren sich die Entwickler. <br /><br /> An dieser Stelle seien sich auch endlich einmal alle Entwickler einig, wie Fox betont: "Softwareentwickler wollen eine ausführliche, gut geschriebene und akkurate Dokumentation - aber selber machen wollen sie es nicht." - Meetings
Meetings sind nicht nur für alle anderen ein Problem, sondern auch für Softwareentwickler. Insbesondere dann, wenn es sich um völlig unnötige, zeitraubende und stinklangweilige Zusammenkünfte handelt. Wie Fox erzählt, sind inzwischen auch Devotionalien mit der Aufschrift 'I survived another meeting that should have been an email' erhältlich. - Coworking Spaces
Mit dem Aufstieg der Agilität sind flache Hierarchien, Collaboration und Teamwork zum Alltag in Unternehmen geworden - insbesondere für Software-Development-Teams. Gerade die können ihre Arbeit in einem Großraumbüro aber meist nur schwer oder gar nicht bewältigen - sagen zumindest die Zahlen von devRant. <br /><br /> David Fox erklärt: "Es gibt einfach zuviel Ablenkung: die Kollegen unterhalten sich, Meetings werden verpasst, Telefonanrufe überhört. Es gibt auch eine Vielzahl an Beschwerden über den Kaffee im Büro und andere Annehmlichkeiten - oder eben das Gegenteil davon." - Kollegen
Selbsterklärend: Jeder hat wohl einen Kollegen oder eine Kollegin, den beziehungsweise die er ganz besonders schätzt. Nicht. <br /><br /> Im Fall der Softwareentwickler ist die Abneigung gegenüber Kollegen meist entweder in der mangelnden Qualität ihrer Arbeit oder einem völlig aus dem Leim gegangenen Ego begründet, gibt David Fox preis. - Vorstellungsgespräche
Wenn ein Softwareentwickler auf Jobsuche ist und zum Bewerbungsgespräch geladen wird, gibt es danach meist auch etwas zu meckern: <br /><br /> "Dumme Fragen oder die Lösung von völlig praxisfernen Aufgaben im Bewerbungsgespräch stoßen den Developern ebenso sauer auf, wie ein Gesprächspartner, der überhaupt nicht weiß, was ein Entwickler eigentlich genau macht", so Fox. - Fehler & Bugs
Softwareentwickler haben tagein, tagaus mit Fehlern und Bugs zu tun. Deswegen glaubt devRant-Gründer Fox, dass Entwickler in dieser Sache anders ticken: <br /><br /> "Die meisten anderen Probleme erfahren keine positive Auflösung, aber Bugs und Fehler sind behebbar und das fühlt sich gut an." - Quality Assurance
Die Quality Assurance (QA) - oder Qualitätssicherung - ist ein kritischer Teil der Softwareentwicklung. Dennoch bemängeln Softwareentwickler an QA-Experten häufig dieselben Dinge wie an Produkt- und Projektmanagern, so Fox. <br /><br /> "Die Qualitätssicherung bekommt das Produkt oder Projekt in die Hände, wenn die Entwickler es abgeschlossen haben. Deswegen verstehen sie oft nicht, welche Hürden und Workarounds die Entwickler im Entstehungsprozess bewältigen mussten. Offensichtlich kommt es auch regelmäßig vor, dass QA-Leute die Entwickler bitten, Bereiche nochmals zu überarbeiten, die sie auch selbst bewältigen könnten."
COBOL - Herausforderungen
Viele COBOL-Applikationen laufen seit den 70er Jahren, die Unternehmen sind abhängig von ihnen und können sich nur schwer lösen. Da oft nur geringe Modifikationen nötig sind, können die Anwendungen mit geringer Manpower gepflegt werden. Da COBOL-Programmierer kaum noch zu bekommen sind, wachsen die Risiken.
Das sCOBOL immer noch eine Rolle spielt, hat auch historische Gründe in den Hardwarearcchtiekturen. Mainframes spielten jahrzehntelang eine tragende Rolle: Sie waren auf Rückwärtskompatibilität und Legacy-Apps ausgelegt - und zwar über mehrere Hardware-Generationen hinweg bei nur minimalen Anpassungen. Das Resultat: Milliarden von COBOL-Zeilen laufen seit Dekaden unverändert.
Im Laufe der Jahre hat sich COBOL kaum noch weiterentwickelt. Längst gibt es mit OO-COBOL auch eine objektorientierte Variante, die modernere Features wie Unicode, Locales und andere Datentypen als Strings und Integers unterstützt. Doch auch diese Anpassungen ändern nichts daran, dass ein COBOL-Programm ein COBOL-Programm ist.
Nicht alle Designentscheidungen der COBOL-Macher stießen bei Programmierern auf Gegenliebe. Einige Features sorgten für übermäßig komplexe Programme, die schwer verständlich und noch schwieriger zu debuggen waren. Der GO TO-Befehl erlaubte Codern beispielsweise (wie bei C) frei durch das Programm zu springen. Eine undisziplinierte Nutzung des Befehls machte COBOL-Applikationen zu schwer zu durchschauenden Gebilden mit einer unüberblickbaren Zahl von Querverweisen.
COBOL Programmierer gesucht
COBOL lebt heute in verschiedenen Formen weiter:
IBM hält weiterhin eigene COBOL-Implementierungen und -Applikationen vor;
Mit Micro Focus COBOL gibt es eine kommerzielle Variante, die auf Windows-Systemen läuft, COBOL-Apps in Java und .NET kompiliert und sich sogar in Cloud-Umgebungen ausrollen lässt;
Open-Source-Implementierungen wie GnuCOBOL sind frei verfügbar und kompilieren zu nativem Programmcode - allerdings sind einige Deployment- und Debugging-Optionen der kommerziellen Versionen hier nicht verfügbar.
COBOL-Know-how zu finden, wird von Jahr zu Jahr schwieriger. Nicht wenige Spezialisten wurden schon aus dem Ruhestand geholt, um alte Applikationen ins 21. Jahrhundert zu überführen. Dabei geht es meist nicht um dezidiertes COBOL-Know-how, sondern eher um das Verständnis für die Mainframe-Umgebungen, in denen die Anwendungen laufen. Viele COBOL-Applikationen gehen Hand in Hand mit Legacy-Technologien wie IBMs hierarchischem Datenbanksystem IMS, dem Transaktionsmonitor CICS sowie diversen anderen Systemen, für die es heute kaum noch Experten gibt.
Deswegen steigt der Bedarf für COBOL-Programmierer kontinuierlich Jahr für Jahr - Jobausschreibungen im Bereich Common Business Oriented Language sind im Überfluss vorhanden.
COBOL lernen
Sich mit der Dino-Sprache vertraut zu machen, mag Programmierer quälen, doch es könnte sich lohnen. Spezialisten werden sehr gut bezahlt. Wer einsteigen möchte, dem bieten sich einige Optionen an:
Die University of Limerick in Irland bietet einen vollständigen Online-Kurs, der die Grundlagen der Programmierarbeit mit COBOL abdeckt.
Das Open Mainframe Project (Teil der Linux Foundation) offeriert ebenfalls Weiterbildungen zum Thema COBOL an. Eines der Angebote wird von IBM co-gesponsert und ist entsprechend auf die (weit verbreitete) IBM-zOS-Implementierung ausgelegt.
COBOL gehört seit Jahrzehnten zur Business IT - und das wird sich auch nicht so schnell ändern. Wenn Sie als Softwareentwickler Interesse an COBOL haben, kann sich ein Einstieg immer noch lohnen. (fm)
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.