Benutzung von Cobol in Banken

Mechanics

cobolfreak schrieb:

1. Möglichst schnell - also sehr maschinennah
2. Unterstützung effiziente I/O Verarbeitung und Datenbanken
3. Unterstützung kaufmännischer Berechnungen
4. Hardwarenahe Stringbearbeitung
5. Strukturierte Programmierung
6. Leicht lesbar und damit leicht wartbar
7. Klare Trennung von Daten und Code
8. Klare Schnittstellen zu Unterprogrammen und damit gekapselte Datenbereiche in den Programmen
9. Gut dokumentiert

LOL

pferdefreund

Es geht auch heutzutage klein - aber das gross macht unter Z/OS auf Wunsch der Editor selber. Ist also kein Aufwand mit Umschalttaste usw.
Z/OS, MVS, VSE-ESA das ist eine ganz andere Welt wie die PC-Umgebung.
Ich habe unter MVS 3.8 - so Stand 1973 eine komplette Jobverwaltung entwickelt und dann 2015 die Programme ohne neu zu kompilieren auf eine Z/OS gespielt. War eine Entwicklung mit COBOL 68 und Assembler. Und wisst ihr, was die machten ? Liefen problemlos. Sind ja nur 30 Jahre Unterschied vom Betriebssystem her. Das nenne ich Investitionssicherheit. Das kann ausser IBM keiner bieten. Weder Windows, MAC, Linux noch BSD und wie sie alle heißen.

cobolfreak schrieb:

Zum Schluss noch ein kleiner Hinweis: man rechne mal aus, wieviele Transaktionen (oder sagen wir zum besseren Verständnis: Buchungen) am Monatsende nur in Deutschland
anfallen (Gehälter, Sozialabgaben, Renten, Versicherungen, Mieten, Strom, Gas, Wasser, Ratenzahlungen, Kreditkarten, TV und und und) - Richtig: Das geht
in die mehrfache Billione

Wow, du hst schon elf Punkte aufgezählt. Dann fehlen ja nicht mehr viele bis zu den von dir versprochenen mindestens 25.000 Buchungen pro Person und Monat. Aber Milliarden hat schon wieder viel zu handhabbar geklungen, nicht wahr?

pferdefreund

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 aber bei anderen Systemen genau so. Da gab es mal einenMP3-Encoder, der war in Assembler geschrieben und damit locker 2 - 3-fach schneller wie seine c-konkurrenten. Ü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.

m.e. schrieb:

Wow, du hst schon elf Punkte aufgezählt. Dann fehlen ja nicht mehr viele bis zu den von dir versprochenen mindestens 25.000 Buchungen pro Person und Monat. Aber Milliarden hat schon wieder viel zu handhabbar geklungen, nicht wahr?

Nun - das sind ja nur typische Beispiele, die am Monatsende anfallen. Hinzu kommt das "dayly business" - etwa der Zahlungsverkehr, Börsentransaktionen, interne Transaktionen - und nicht vergessen, dass fast jede Buchung über die Zentralbanken gecleard werden müssen.
Ich gebe aber zu, dass Anzahl Transaktionen nicht viel taugt - genausowenig wie etwa ein Betrag, der täglich über diese Rechner abgewickelt wird. Vielleicht wäre das Datenvolumen eine bessere Grösse... Jedenfalls ist es enorm, was auf diesen Grossrechnern läuft.

pferdefreund schrieb:

Es gibt sogar mittlerweile auch Pointer usw. in Cobol und auch einen freien Cobol-Compiler, den ich sehr intensiv nutze. Einfach mal nach OpenCobol googeln, da findet man den Compiler der momentan
sehr aktiv entwickelt wird.

Cobol macht doch eigentlich nur Sinn, wenn das System alles unterstützt. Was für einen Sinn macht etwa eine "File Section", wenn das System keine I/O Channels unterstützt? Oder was soll eine FD (File Description), wenn das System kein "F", "V" oder "U" Fileformate unterstütz??
Ich schrieb ja in meinem ersten Post, dass Cobol nur Sinn macht, wenn es sehr nahe an der Hardware resp. BS compiliert werden kann.

pferdefreund schrieb:

Es geht auch heutzutage klein - aber das gross macht unter Z/OS auf Wunsch der Editor selber. Ist also kein Aufwand mit Umschalttaste usw.
Z/OS, MVS, VSE-ESA das ist eine ganz andere Welt wie die PC-Umgebung.
Ich habe unter MVS 3.8 - so Stand 1973 eine komplette Jobverwaltung entwickelt und dann 2015 die Programme ohne neu zu kompilieren auf eine Z/OS gespielt. War eine Entwicklung mit COBOL 68 und Assembler. Und wisst ihr, was die machten ? Liefen problemlos. Sind ja nur 30 Jahre Unterschied vom Betriebssystem her. Das nenne ich Investitionssicherheit. Das kann ausser IBM keiner bieten. Weder Windows, MAC, Linux noch BSD und wie sie alle heißen.

Das mit der Investitionssicherheit ist ja schön und gut. Aber auch hier gibts Nachteile. Das ganze Dillema des Hosts sind genau diese "Altlasten". Man hatte eine Applikation - die lief wunderbar - die Programmierer gingen in Rente und dann Wer wartet jetzt Programme aus den 70er Jahren. Ich habe bei einem deutschen Automobilhersteller mal ein solches Cobolprogramm warten müssen. Da waren sage und schreibe ca 100 "GO TO" drin...

Das ist eigentlich aber alles jetzt OT.

Vielleicht so viel zum Beginn des Threads: Cobolprogrammierer sind ein "elitäres Grüppchen" - jedenfalls im deutschsprachigen Raum und als Freelancer - man kennt sich
Der Einstieg ist recht hart: Man sollte mindestens 4 Jahre Praxis nachweisen können - und das als Einsteiger für relativ kleines Geld (30-40k/y). Wenn man dann den Freelancerweg gehen will, muss man wissen, auf was man sich einlässt - aber das ist bei einem C++ Programmierer ähnlich - und da überlasse ich das Feld gerne den Kollegen hier, Dir mit Rat zur Seite zu stehen.....

Laut https://www.gulp.de/stundensatzkalkulator verdienen Cobol-Programmierer durchschnittlich 72 € als Externer. Also nicht mehr oder weniger als mit anderen Sprachen.

Hat hier eig. schon mal einer mit Software Geld verdient

bambi schrieb:

Hat hier eig. schon mal einer mit Software Geld verdient

Natürlich ausser den Typen, die sonst Musik machen oder Bilder malen würden, die zählen nicht

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.

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?

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.)

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.