Irgendwie war mir das schon klar, dass Cobol sehr alt ist. Aber dass gestern offenbar der Tag des 50. Geburtstages war, ist mir nicht bewusst gewesen.
Ich selbst habe vor einiger Zeit mal ein bisschen Cobol-programmiert, und bin ganz froh darüber, dass ich es lesen kann und auch mal mitreden, wenn’s um Cobol-Themen geht. In den Projekten, durch die ich mich so kämpfe, ist Cobol fast immer die Sprache auf dem Back-End, also dem dicken IBM-Hobel im klimatisierten Hochsicherheitskeller.Und das, was Cobol da tut, tut es in beeindruckend schneller und stabiler Weise: Massendaten durchmassieren und von A nach B schaufeln. Das Gespann Großrechner und Cobol ist da ziemlich ungeschlagen das performanteste, was es gibt.
Umso schlimmer finde ich, dass man sehenden Auges in eine Situation hinein schlittert, die katastrophaler nicht sein könnte: Cobol ist bald nur noch was für alte Recken oder verkrachte EDV-Quereinsteiger, die sonst nix drauf haben. Dabei bewegt Cobol weltweit dermassen viele Daten und damit auch Geld, dass es befremdlich und unheimlich ist, zu sehen, wie stiefmütterlich sowohl der Mainframe als auch Sprachen wie Cobol oder PL/1 behandelt werden, wenn es um den Aufbau von KnowHow und die Ausbildung von Nachwuchs geht.
So hip und sexy Web und Rich Client sein mögen, so unbedeutend sind sie doch (leider?), wenn es um die Verarbeitung von Buchungen, Lastschriften, Abbuchungen, Massenmailings und so weiter geht.
Keiner bildet mehr Cobol aus, schon gar nicht unsere Universitäten, denn Cobol ist ja simpel und schon so alt. Mir hat man im Studium Anfang der neunziger Jahre erzählt, bis ins Jahr 2000 gäbe es den Mainframe nicht mehr. Das macht dann alles eine Unix-Maschine. Zwar hinkt dieser Vergleich ziemlich, denn das eine schliesst das andere ja nicht aus, aber das war den Herren Professoren wohl so noch nicht aufgefallen. Und mit der geänderten Hardwarearchitektur würde dann auch alles aussterben, was man auf dem Hobel damals eben so machte. Und damit auch Cobol.
Zugegeben, wir haben heute bunte und intuitivere Oberflächen in der Hinterhand als einen 3270-Bildschirm in Bernstein oder mit 6 Farben, und mehr als 80*25 Zeichen können heute sogar unsere Mobiltelefone darstellen.
Aber wir scheinen gerne zu vergessen, dass die Erfassung und Plausibilisierung von Daten zwar eine wichtige und unterstützenswerte Aufgabe ist, aber in den meisten unserer Projekte steckt am Ende ein Jobnetz aus Batchprozessen am Host, die dann morgends um Drei Uhr im bereits angesprochenen Keller die Schmutzarbeit machen.
Ein paar interessante Zahlen zum Thema aus dem Heise-Artikel:
- weltweit 200 Milliarden Zeilen an Cobol-Code, und es kommen mehrere hundert Zeilen täglich hinzu. (Anmerkung des Autors: es sind ganz sicher deutlich mehr als ein paar hundert pro Tag!)
- Ungefähr 1,5 bis 2 Millionen Entwickler haben mit Cobol-Code zu tun.
- David Stephenson von dem britischen Cobol-Experten Micro Focus geht davon aus, dass heute 200-mal mehr Cobol-Transaktionen täglich durchgeführt werden als Suchanfragen bei Google.
Ist es nicht Wahnsinn, dass wir uns keinen Cobol-Nachwuchs mehr heranziehen, ohne bereits heftigst an einer geeigneten Nachfolgetechnologie zu arbeiten? Sind wir nicht ziemlich schräg unterwegs, wenn man bedenkt, dass wir noch nicht einmal eine müde Idee davon haben, wie diese Nachfolgetechnologie aussehen könnte?
Und selbst wenn wir schon eine hätten, wie lange müssen wir wohl in die Zukunft schauen, bis diese die bestehende ersetzen kann.
Jeder, der schonmal einen neuen Buchungslauf eingeführt hat, oder unter der alljährlichen Urlaubssperre zum Jahreswechsel dem großen GAU entgegengefürchtet hat, weiss, wieviel vergessenes Know-How und Detailwissn in diesen teilweise 30 Jahre oder noch älteren Programmen steckt. Wieviel Testaufwand steckt in diesen Systemen? Ich vermute, wir können hier global betrachtet von einigen Taused Personenjahren ausgehen.
Heise schliesst seine Geburtstagslaudatio mit den Worten:
Spannend dürfte für die Zukunft sein, wie viele Systeme Firmen aufgrund mangelnder Programmierer mit Cobol-Know-how auf andere Programmiersprachen wechseln.
Die Frage ist nur, auf welche sollte das sein?
Java-Batchprozesse? Technisch sicher machbar, und das Zeug zur Legacy hat Java ja durchaus.
Ruby on Iron? Immerhin sehr hip zur Zeit.
Wie lange werden diese Technologien leben, und welchen Vorteil hätte man daraus, eine neue Technologie mit Milliardenaufwänden zur Legacy von Morgen zu machen?
Sterben uns dann in dreissig Jahren nicht wieder die Ruby-Batch-Programmierer aus? Okay, wir hätten dreissig Jahre gewonnen, und die Konjunktur enorm gefördert.
Wieso denn überhaupt eine neue Technologie, wenn die alte doch eigentlich keinen Anlass zur Klage gibt, ausser, dass wir uns selbst den Nachwuchs abschrecken?
Achja, und egal, welche Programmiersprache man sich immer aussucht: schnödes Datenmassieren ist es allemal.
Wahnsinn…
