COBOL ist nicht zeitgemäß: Neun Vorurteile gegen die trivialste aller Programmiersprachen

COBOL gilt vielen als veraltet. Die Programmiersprache sei allenfalls für den Mainframe zu gebrauchen und auch dort nur begrenzt, weil es an der Integrierbarkeit in moderne IT-Systeme hapere. COBOL-works widerlegt einen Großteil dieser Vorurteile und zeigt auf, weshalb es auch heute immens wichtig ist, weiter auch auf COBOL zu bauen.

Dass die COBOL-Standards von heute mit anderen Sprachen mithalten können und moderne Compiler mit allen gängigen Datenbanken und Schnittstellen kompatibel sind, hat sich indes noch nicht herumgesprochen.

  1. COBOL braucht heutzutage niemand mehr.

    Viele Unternehmen – vornehmlich der öffentlichen Hand, Banken und Versicherungen, aus der Touristik- und Telekommunikationsbranche sowie viele Industriebetriebe – verarbeiten ihre betriebswirtschaftlichen Daten seit jeher mit Programmen, die im Kern auf COBOL basieren und auf Großrechner- und LUW-Systemen laufen. Hinzu kommen Tausende von Software- und Systemhäusern (ISVs), die ihre Anwendungen oder Teile davon in COBOL entwickeln. Dort werden sie zusammen mit neueren Anwendungen aufgerufen, die meist in Java, C++ oder C# geschrieben sind. Dass COBOL auch heute noch so verbreitet ist, mag am schieren Risiko liegen, das von Neuentwicklungen ausgeht. Aber vor allem ist die große Verbreitung den Vorteilen von COBOL zu verdanken, an die auch das moderne Java nicht herankommt. COBOL gilt unter erfahrenen Entwicklern als ausgesprochen klar und flexibel. Insbesondere wenn stringente Daten verarbeitet werden sollen, ist COBOL auch heute C oder Java gegenüber weiterhin klar im Vorteil.

  2. COBOL ist eine Sprache für Großrechner. Mit den Mainframes stirbt bald auch COBOL.

    Diese Aussage ist nicht richtig. Mit der hohen Leistungsfähigkeit moderner Midsize-Systeme (LUW) verabschieden sich viele IT-Abteilungen von ihren Großrechnern und steigen auf kleinere, offene Systeme um. Sie sind im Unterhalt kostengünstiger. Dass sie auch dort weiter auf die altbewährten Logiken ihrer COBOL-Anwendungen vertrauen können, wissen nur wenige. Mit den kleineren Rechnern sparen sie so doppelt, denn die oftmals für notwendig erachtete Neuprogrammierung der Anwendungen kann dank moderner Modernisierungs- und Rehosting-Tools entfallen. Unternehmen wie COBOL-works haben sich auf die Modernisierung altbewährter Programme spezialisiert. Zudem ist in Zeiten von Attacken auf Cloudsysteme und Abhöraktivitäten der NSA oder anderer Geheimdienste tendenziell eher von einem steigenden denn fallenden Bedarf an Mainframe- bzw. Non-Stop-Systemen auszugehen.
    COBOL ist mitnichten eine reine Großrechner-Sprache, sondern versteht sich heute mit allen gängigen Plattformen, sei es Unix, Linux oder Windows in 32 oder 64bit. Der Compiler COBOL-IT beispielsweise ist für 6 verschiedene Plattformen verfügbar sowie für alle Formen der Datenverwaltung (ISAM, RDBMS, Netzwerk/hierarchische wie auch NoSQL-Datenhaltung) sowie für alle Zeichensätze wie ASCII, ANSI, EBCDIC und Unicode.

  3. Weil COBOL-Entwickler aussterben, sind IT-Abteilungen gezwungen, die Pferde zu wechseln.

    Ein auf den ersten Blick nicht ganz von der Hand zu weisender Nachteil von COBOL liegt im zunehmenden Alter der derer, die gelernt haben, in dieser Sprache zu entwickeln. Von 357 IT-Fachleuten, die im Mai 2012 im Rahmen einer Umfrage* der Zeitschrift Computerworld zum Einsatz von COBOL in ihren Unternehmen befragt wurden, gaben 46% an, eine nachlassende Verfügbarkeit von COBOL-Programmierern zu spüren. 50% sagten, ihre COBOL-Entwickler seien 45 Jahre alt oder älter, knapp ein Fünftel gab das Durchschnittsalter mit 55 an. Neue COBOL-Entwickler werden nur von wenigen Unternehmen ausgebildet. COBOL gilt vielen einfach als nicht sexy genug. Dass das nicht so sein muss, zeigen Dienstleister wie die Firma COBOL-works GmbH, die weiterhin COBOL-Entwickler beschäftigt und ausbildet und so einen wachsenden Markt für sich erschlossen hat. Die Computerworld-Untersuchung ergab, dass vier Fünftel aller Befragten die Wartung ihrer COBOL-Anwendungen ausgelagert haben. Denn während der absolute Anteil von COBOL-Installationen nach Angaben des US-amerikanischen Meinungsforschungsinstituts Gardner in den vergangenen Jahren weltweit mit schätzungsweise -5% leicht rückgängig ist, so verarbeiten Abertausende COBOL-Programmen nach wie vor Aufgaben so zuverlässig, dass es häufig sinnvoll ist, sie zu erhalten. Denn COBOL-Logik lässt sich heutzutage kapseln, auf andere Systeme verlagern und dort im Verbund mit C#- oder Java-Anwendungen betreiben. Die wirkliche Herausforderung liegt nicht in der Sprache COBOL – sie kann in wenigen Monaten gelernt werden – sondern darin, dass die Anwendungen in komplexen Umgebungen laufen, administriert, gepflegt und entwickelt werden wollen. Diese komplexen Umgebungen müssen beherrscht werden – unabhängig von der Sprache!

  4. COBOL kann nicht in moderne Umgebungen integriert werden.

    Falsch: Mit Eclipse- oder Visual-Studio-basierten Entwicklungsumgebungen gibt es heute ausgereifte Entwicklungs- und Migrationswerkzeuge, die geplant und schrittweise Kernprozesse der Entwicklung als auch die Produktion, den Betrieb z.B. nach Java oder .NET überführen können. COBOL-Code kann im Rahmen eines übergeordneten Projekts übersetzt und später entweder Schritt für Schritt abgeschaltet oder gekapselt und in anderen Code integriert werden. Dadurch kann auch für altbewährte Anwendungen eine moderne Oberfläche geschaffen und dank zahlreicher Schnittstellen an moderne Umgebungen angebunden werden. Auch Applikationen für das Web und moderne Endgeräte können auf diese Weise Verwendung finden.

  5. Für die Zwecke, für die wir COBOL noch benötigen, sind die Compiler einfach zu teuer.

    Der traditionsbedingte Einsatz von COBOL in großen IT-Infrastrukturen brachte es in der Vergangenheit mit sich, dass COBOL-Compiler und die damit assoziierten Produkte tatsächlich in höheren Preisligen angesiedelt waren. Mit den auf Open Source basierenden Compilern von COBOL-IT müssen Unternehmen sich kein teueres Allround-Paket ins Haus holen, das sie nicht benötigen. Im Gegensatz zu vielen anderen Compilern wird COBOL-IT im Rahmen einer so genannten Subscription vertrieben. Das heißt: Unternehmen erwerben die Nutzungsrechte und den dazugehörigen Support nur für die Module (Compiler, Precompiler, IDE usw.), die sie benötigen und auch nur solange, wie sie im Einsatz sind. Damit reduzieren sich die Anschaffungskosten drastisch, und Unternehmen können flexibel auf Veränderungen ihrer IT-Landschaft reagieren.

  6. Wir wissen gar nicht, wie viel COBOL-Code wir haben. Hoffentlich muss da niemand mal ran.

    Tatsächlich verrichten COBOL-Programme in vielen Unternehmen seit Jahrzehnten still und heimlich ihren Dienst. Modernisierungen werden daher häufig solange herausgezögert, bis die Unternehmen gezwungen sind, große Teile ihrer Infrastruktur zu ersetzen. Sei es weil der ökonomische Zwang zu groß wird, weil die Unterstützung für andere Software-Tools oder -Module eingestellt wird, oder weil die Kompatibilität zu modernen OS- und Entwicklungsplattformen erforderlich wird. Da diese Entscheidungen gravierend sind, sollten hier unabhängige Lösungsanbieter ins Boot geholt werden, die mit den damit verbundenen Aufgaben vertraut sind und andere Unternehmen bei ihrer Entscheidung unterstützen können.

  7. Die Standards sind veraltet.

    Falsch: Auch nach über 50 Jahren wird der COBOL-Standard immer noch angepasst. Der neueste COBOL-Standard wurde im Jahre 2002 verabschiedet. Dabei wurden neben zahlreichen Präzisierungen internationale Zeichensätze (UTF-8), die objektorientierte Programmierung sowie die das bedingte Kompilieren in den Standard aufgenommen. Eine für 2010 geplante Version wartet noch auf ihre Fertigstellung. Alle gängigen Compiler sind mit ANSI85 kompatibel. Die meisten Deklarationen aus COBOL 2002 werden ebenfalls unterstützt.

  8. COBOL versteht sich nicht auf Objektorientierung.

    Falsch: Der COBOL-Standard ISO 2002 versteht sich COBOL sehr wohl auf Objektorientierung.

  9. Es ist günstiger, Anwendungen neu zu schreiben, als weiter COBOL-Code zu pflegen.

    Das könnte man denken. Doch Erfahrungen zeigen, dass das Gegenteil der Fall ist. In der Praxis ist die Neuprogrammierung in Java oder C# mit einem erheblichen technischen und daher finanziellen Risiko verbunden. Viele Logiken lassen sich in den jüngeren Sprachen weit weniger elegant umsetzen. Die Entscheidung für oder gegen eine Zukunft mit COBOL sollte daher im Verbund mit Migrationsexperten getroffen werden. In der Regel ist das Ergebnis keine Hopp-oder-topp-Entscheidung, sondern ein zeitlich wie inhaltlich genau getaktetes Migrationsprojekt, dem eine umfassende Analyse der IT-Infrastruktur vorausgeht. Am Ende des Projekts steht eine Anwendung, die aus COBOL und den „neuen“ Sprachen besteht.