kleine Randbemerkung zu einem untergordneten Aspekt Deines Beitrags:

[...] - auch in Banken und Versicherungen laufen z. T. noch Großrechneranwendungen,

bei der Großbank, für die ich bis vor fünf Jahren als Anwendungsentwickler tätig war, bildet der Mainframe nach wie vor das Rückgrat der IT, ohne ihn liefe in dem Laden überhaupt nichts. Die Großrechner-Hardware ist auf dem neuesten Stand und die hochkomplexe, für ein kleines Licht wie mich nicht überschaubare Software-Landschaft (zumeist in COBOL programmiert) wird von hunderten von Entwicklern gewartet und permanent weiterentwickelt.

Ja, nur, daß solche Organisationen immer mehr ins Hintertreffen geraten, was modernere Programmiersprachen und objektorientiertes Programmieren betrifft. Auch Ericssons Telefonvermittlung läuft auf Milliarden Zeilen "strukturiert programmiertem" Spaghetti-Code.

Seit der NATO-Softwarekrisenkonferenz 1968 weiß man aber, daß das eine gefährliche Sackgasse werden kann. Daß man dann stattddessen ADA aus der Taufe hebt, ist dem geschuldet, was der legendäre Dijkstra über COBOL sagte: "A camel is a horse designed by a committee".

So sieht es, soweit mir bekannt, bei allen großen Banken aus.

Nein, diejenigen, die auf SAP (R/3 bzw. HANA)-Banking umgestellt haben (oder IS Insurance), sind schon längst auf Client-Server - vgl. Postbank.

An der Expertise würde eine Umstellung auf Client-Server-Systeme wohl nicht scheitern angesichts der Heerscharen von COBOL-Entwicklern, Datenbank- und System-Admins, die sich bei den Banken tummeln und von denen einige sogar unter siebzig Jahre alt sind ; ich vermute in erster Linie Kostengründe (eine solche Aktion würde Unsummen verschlingen), vor allem aber Sicherheitsaspekte, die einem Systemwechsel im Wege stehen.

Es ist von Institution zu Institution ganz unterschiedlich.

So kenne ich z.B. eine Großbank, die noch 16 Jahre nach offiziellem Wartungsschluß SIEMENS BS1000 auf ihren Rechnern hatte. Als nun Siemens seinerseits die BS1000-erfahrenen Entwickler wegstarben, wurde es brenzlig und sie bekamen die Pistole auf die Brust gesetzt. Man migrierte dann nolens volens auf BS2000. Mit dem EDT wurden auch schon mal die Kontoauszüge erstellt, wenn die hierarchische Datenbank mal wieder nicht so ganz in der Übergangsphase mit der neueren relationalen Version UDS harmonieren wollte.

Auch der einstige Großrechner-Hersteller Siemens machte schon 1996 die Kehrtwende: SIEMENS TO PHASE OUT MAINFRAMES: BS2000 ON R4400. (Das BS3000 war übrigens kein Nachfolger von BS2000, sondern ein Fujitsu-OS.)

Ein ordentlich administrierter z/OS Mainframe ist von außen nicht hackbar

Auch hier ein kleiner Einspruch: die ersten Hacker, die diesen Namen überhaupt begründet haben, waren Jungs, aus meist gutem Hause, die sich in große Rechenanlagen, zuvörderst ihrer eigenen Universitäten, aber auch in andere Unternehmens-Rechenzentren "eingehackt" haben, um sich "Zeitscheiben" aus dem Time-Sharing-Betriebssystem zu 'klauen', da damals (in den sechziger und siebziger Jahren) keiner über einen Computer verfügen konnte, weil es diese Tischgeräte in größerem Umfange erst seit Anfang der achtziger Jahre gab.

Die zweite Zielscheibe der Hacker waren die Telefonanlagen von ATT und den "Baby-Bells", d.h. sie manipulierten mit Modems in Telefonzellen usw. die Systeme so, daß sie kostenlose Fern- und Auslandsgespräche führen konnten. Einer schaffte es gar, eine offiziell nicht existierende Brücke zwischen dem Telefon- und dem Fernschreibernetz ausfindig zu machen. Und als Krönung und Königsdisziplin galt dann, diese beiden Disziplinen zu vereinen und Rechenleistung der Großrechner über kostenlose Telefon-Datenleitungen nach außen zur Verfügung zu stellen (z.B. über Teletype).

Daß dieses Gebiet derzeit komplett verwaist ist, hat m.E. lediglich damit zu tun, daß der Antrieb, Rechenleistung "zu klauen" weggefallen ist, seit jedes Kind die Rechenleistung mehrerer Großrechenzentren der siebziger Jahre auf seinem Hausaufgabentisch stehen hat und so auch jeder 'Hacker'.

Siehe auch Hacking History – A Timeline Of Hack Tactics [Infographic].

Diese Anfangsgründe sind mit u.a. überraschenden Reminiszenzen, z.B. in Büchern beschrieben wie:

- Hackers: Heroes of the computer revolution

- Underground: Die Geschichte der frühen Hacker-Elite

- Dreiundzwanzig - 23 - Die Geschichte des Hackers Karl Koch

- Kleine Kulturgeschichte des Hackens

- On the Way to the Web: The Secret History of the Internet and Its Founders

- Nerd Attack!: Eine Geschichte der digitalen Welt vom C64 bis zu Twitter und Facebook

In beiden Fällen müht man sich seit Jahren, auf Client-Server zu migrieren, mit durchwachsenem Erfolg ...

Tja, das ist so eine Sache. SAP hat es relativ problemlos damals geschafft, von SAP R/2 (Mainframe) auf R/3 (Client-Server) umzustellen. Kann man meiner Erinnerung nach in "SAP, die heimliche Software-Macht" nachlesen. Jedenfalls lief das so: man portierte den R/2-ABAP-Code auf IBM-Rechner und stellte sie auf der Systems in München oder der CeBit auf (weiß ich nicht mehr). Es lief fast auf Anhieb. Da aber die Kunden, die ja alle nur R/2 kannten, auf der Messe nicht glauben wollten, daß das auf den kleinen IBM-Workstations "performant" läuft, legten die Messe-Betreuer von SAP noch ein dickes Kabel vom Tisch mit den IBM-Rechnern nach hinten und sagten, das sei "die Standleitung nach Walldorf", denn es bestand die Gefahr, daß die Manframe-gewöhnten Kunden den Eindruck bekommen könnten, SAP sei keine ernstzunehmende Unternehmenssoftware.

Das hat SAP vor allem diesem Mann zu verdanken, der jahrelang mit darauf bestand, daß ABAP wurde, was es ist und sich auf keine externen Experimente einließ (anfangs war es noch der "Allgemeine Berichts-Aufbereitungs-Prozessor" (anfänglich ähnlich IBM RPG).

Wie die Zeiten sich geändert haben ...

--
Literatur-/Produkthinweise. Alle Angaben ohne Gewähr! - Leserzuschriften