Benutzung von Cobol in Banken

[Mit Rust]

cobolfreak schrieb:

Richtig: Das geht
in die mehrfache Billionen - natürlich revisionsfähig und daher mit Journalisierung und anderen Mechanismen. Und sowas wollt ihr mit C++ umsetzen? -
es darf gelacht werden....

Rust!

Denn sonst kommen die Progger von Morgen in 30 Jahren und beschweren sich über uns, für den C++ Saustall, den wir ihnen hinterlassen haben.

[Kenner der Sprachen]

Haskell FTW

[hustbaer]

pferdefreund schrieb:

und nicht vergessen -im Großrechner-Umfeld wird auch noch relativ viel mit Assembler gemacht - insbesondere bei zeitkritischen Anwendungen. Da geht es aber dann wirklich ans "Eingemachte".

Ja, da wird noch viel assemblert. Und weisst du auch wieso? Weil die Kisten dreckselendiglich langsam sind.

pferdefreund schrieb:

Übrigens - der Z/OS-Cobol-Compiler macht heute noch aus dem Quelltext erst mal Assembler. Das ist dann auch sehr hilfreich bei der Fehlersuche weil man sieht, welche Instruktion denn nun wirklich zum Abkacken geführt hat.

Oh, wie schade dass man mit C++ Toolchains nicht an den generierten Assemblercode drankommen kann
Ernsthaft, hast du schonmal mit irgend einem modernen System gearbeitet?

[zufallswert]

hustbaer schrieb:

Ja, da wird noch viel assemblert. Und weisst du auch wieso? Weil die Kisten dreckselendiglich langsam sind.

Kannst du diese Behauptung belegen?

[asc]

Irgendwie habe ich das Gefühl man sollte in einem C++ Forum ja keine sinnvollen Antworten erwarten, wenn diese zu anderen Sprachen gestellt werden. Ich gebe hier einfach mal Wertneutral wieder, was ein Informatiker aus dem Stuttgarder Raum, vor etwa einem Jahr hier gesagt hat:

1. Unternehmen kommen wieder verstärkt auf Universitäten zu mit der Bitte auch wieder Großrechner (und auch Cobol) zu berücksichtigen.
2. Ein IBM-Großrechnerschrank mit den entsprechenden Prozessoren kann kleine Rechenrentren für Hostig ersetzten.

Ich selbst bin nicht in diesem Gebiet tätig, doch deutet dies für mich darauf das weder Großrechner noch Cobol tot sind, und das die Großrechner nicht so langsam zu sein scheinen wie von hustbaer propagiert.

[hustbaer]

Es kommt drauf an was man darauf laufen lässt und wie viel man bereit ist pro Monat zu zahlen.

Was ungethrottelte z/Architecture CPUs angeht (z/Linux, g++, Hardware ist ne z13), die können pro Core bei entsprechender Workload ca. gleich schnell sein wie ein i7. Also das 5 GHz z Teil verglichen mit nem i7 mit 4 GHz "turbo" Takt. Bei "weniger passender" Workload aber auch gerne mal um einiges langsamer. Schlimm scheinen z.B. Divisionen zu sein, ganz schlimm alles was atomics (CAS) bzw. allgemein Synchronosierung zwischen Threads erfordert (z.B. malloc/free). Hab schon Tests gesehen wo es mehr als Faktor 10 war.

Und sobald man dann auf z/OS ist kommt noch dazu dass man mächtig $$$ an IBM zahlen muss wenn man die volle Performance der z nutzen will. Da ist es nämlich nicht damit getan dass man 6-7-stellige (Dollar-)Beträge dafür zahlt dass die einem ne dicke z hinstellen, sondern man darf pro Monat auch noch ordentlich abdrücken für die freigeschaltenen MSUs.

----

Die IO Anbindung der z Kisten soll ja wirklich ganz gut (sehr gut) sein. So 2-3 Mio IOs/Sekunde wenn ich mich richtig erinnere? Nur wenn man mal guckt was mit normaler PC Hardware so drin ist, und dann die Kosten gegenüberstellt...

[hustbaer]

ps:
Wer viel Rechenleistung in einer Kiste haben möchte, der sollte sich vielleicht besser mal bei den OpenPOWER Teilen umsehen.

[pferdefreund]

Oh, wie schade dass man mit C++ Toolchains nicht an den generierten Assemblercode drankommen kann
Ernsthaft, hast du schonmal mit irgend einem modernen System gearbeitet?

Ja - ich arbeite beruflich mit C und SAP/Abap, Dynpros, reuse_grid_displa usw,
dialoganwendungen, systemnahe Geschichten wie Archivverlegungen usw.
Was halt so anfällt.

das mit dem cobol und MVS mache ich nur noch als Hobby auf meiner simulierten S/370. War aber damals 1982 mein Einstieg in die EDV - ebenfalls mit einer - da allerdings echten - S/370

[hustbaer]

.
Entfernt wegen Unsinn.
(Ja, man kann mich verwirren wenn man meine eigenen Beiträge Auszugsweise quotet ohne zu quoten.)

[Cryptoinvestor]

Scheiß auf Banken!
Crypto ist die Zukunft

[hustbaer]

pferdefreund schrieb:

hustbaer schrieb:

Oh, wie schade dass man mit C++ Toolchains nicht an den generierten Assemblercode drankommen kann
Ernsthaft, hast du schonmal mit irgend einem modernen System gearbeitet?

Ja - ich arbeite beruflich mit C und SAP/Abap, Dynpros, reuse_grid_displa usw,
dialoganwendungen, systemnahe Geschichten wie Archivverlegungen usw.
Was halt so anfällt.

(Quote fixed by me)

Da ist jetzt nix dabei was ich als modern einstufen würde.
OK, Dynpros kenn' ich nicht, mag sein dass das "modern" im Sinn von "nicht sehr alt" ist.

Ich würde dir aber empfehlen mal Visual Studio oder Eclipse CDT oder sowas anzugucken, und was man da so für Möglichkeiten bezüglich Debugging/Assemblercode angucken etc. hat. Bei Visual Studio kannst du dir im Debugger sogar die Disassembly von .NET Programmen angucken. Einfach auf nen Breakpoint drauflaufen lassen und dann im Menu die Disassembly-View auswählen -> fertig. (Also wirklich die Disassembly vom gejitteten Maschinencode, nicht den IL Code.)
Wie bzw. ob das mit Java auch geht weiss ich nicht. (Würde mich nicht wundern wenn es mit der passenden IDE auch ginge, würde mich aber auch nicht wundern wenn nicht.)

[goi]

pferdefreund schrieb:

und nicht vergessen -im Großrechner-Umfeld wird auch noch relativ viel mit Assembler gemacht - insbesondere bei zeitkritischen Anwendungen. Da geht es aber dann wirklich ans "Eingemachte".

Ist das so? In mehr als 10 Jahren HPC-lastiger Arbeit sind mir abgesehen von ein paar kleinen Schnipseln plattformspezifischem ASM, die niemand mehr hinterfragt, höchstens Fortran oder C als low-leveligste Rechenkerne untergekommen. Ansonsten wird in den verbreiteten Libraries viel mit objektorientiertem Fortran, C (z.B. PETSc) oder gar C++ (z.B. Deal.ii) gemacht. Um die "abstraction penalty" kommt man i.d.R. gut herum, weil man oft seine Probleme ziemlich elegant formulieren kann und dann nur beim "number crunching" auf Techniken wie TMP oder weniger abstrakte low-level-Rechenkerne zurückgreift. Der Top-Level-Code, der 90% ausmacht ist bei den Neuentwicklungen der vergangenen 10 Jahre meiner Erfahrung nach sehr oft C++ 98. Modernes C++ sieht man leider noch nicht so häufig weil die Compiler, die man gemeinhin auf Clustern findet, da erst langsam die nötige Reife erlangen oder schlicht auf den infrage kommenden Systemen nicht aktuell genug sind.

[pferdefreund]

Wobei ich mit Großrechner die IBM-Mainfraimes mit Z/OS meine. Ja, da wurden oft zeitkritische Routinen in Assembler geschrieben. War dann in den letzten so 15 Jahren nicht mehr so wichtig aber mit Assembler gehen halt Dinge, die mit einer Hochsprache nicht so zu regeln sind, wie z. B SVC99 und ähnliches. Da gibt es eben nur die Möglichkeit, das mit Assembler zu machen. Damals, in den späen 80ern war vieles, was mit Tabellen zu tun hatte, mit Assembler einfach schneller. Und bei 100.000den von Datensätzen pro täglicher Verarbeitung hat man das schon gemerkt.
Schon das Trennen von Name*Vorname beim * ging mit Assembler locker doppelt so schnell - und solle Trennereien waren damals beim DÜVO-Format üblich.
Heute mit der DEUEV sieht es ja etwas freundlicher aus aber damals gab es viele durch * getrennte Daten in einem Feld bei der Anlieferung, die dann entsprechend der Einzelfelder in der Datenbank auseinandergenommen werden mussten - und das in großen Mengen.

[SeppJ]

In den 80ern war ein Compiler aber auch kaum besser als das, was man heutzutage als "ohne Optimierungen" bezeichnen würde. Da musste der C-Profi selber im Kopf haben, ob nun "geteilt durch 2" auf dem System besser durch / 2 oder << 1 dargestellt werden sollte. Heutzutage wissen die Compiler über alle diese Mikrooptimierungen architekturgenau Bescheid und können diese zudem mit vielen anderen Optimierungen kombinieren, wie z.B. plattformspezifische Optimierungen der Pipelines, Caches und Register. Ein Mensch müsste monatelang tüfteln und ausprobieren, wie er all diese Optimierungen optimal vereint, der moderne Compiler rechnet es hingegen einfach aus.

Besser ist der menschliche Assemblercode praktisch nur, wenn er komplexe Prozessorfeatures, wie z.B. Vektor- oder Kryptobefehle, benutzt, die der Compiler entweder nicht kennt oder deren Anwendungsmöglichkeit er nicht erkennt. Nicht umsonst gibt es für solche Features oft spezielle Bindings für Hochsprachen.