Benutzung von Cobol in Banken
-
i8beef schrieb:
Nein, es macht absolut keinen Sinn Cobol zu lernen. Denn Cobol zu programmieren macht absolut keinen Spaß. Und ohne Spaß wird das Leben trostlos und leer sein.
Aber 200€ die Stunde...
Also kann man festhalten, dass Cobol alleine zwar keinen Spaß bereitet, jedoch Spaß beschert?
-
Ich weiss nicht ob die €200/Stunde nicht etwas übertrieben sind. Also was eine *Anstellung* angeht. Würde ich nochmal nachprüfen bevor du jetzt gross anfängst COBOL zu lernen. Für "angemietete" Consultants/Programmierer kann ich mir das schon vorstellen, bzw. dafür wäre es nichtmal krass viel - ein guter SAP oder Oracle-Spezialist kostet auch nicht wesentlich weniger.
-
trudi schrieb:
EOP-hat-wiedermal schrieb:
Ja, es wird.
Bei der Schweizer UBS z.B. auf Großrechnern.Und warum steigen die nicht so langsam um?
Ist doch viel genehmer mit C++!1. Never change a running system.
2. Das ist so eine Unmenge von Code, der umzustellen/neu zu programmieren wäre - mehrere 1000 Mannjahre wahrscheinlich. Plus die ganzen Schnittstellen zu MySQL und Anderem, die auch neudefiniert werden müssten.Da sind nicht nur 1000 LOC betroffen.
-
trudi schrieb:
delphi schrieb:
Alles umzuschreiben würde aber 100 Millionen Euro kosten. Davon kann man viele Cobol-Programmierer für 200 Euro die Stunde anstellen.
Ergo, es macht definitiv noch Sinn Cobol zu lernen?
200 Euro die Stunde, das klingt wie Musik in meinen Ohren.200€ ist nicht wahr. 20-30€ passt für Cobol-Einsteiger.
Die Programme in Cobol machen gar nichts kompliziertes, niemals. Geld nach links und Geld nach rechts.
Und Cobol ist eine wirklich einfache Sprache. Wenn der Informatiker gerade mal weg muss, kann der Hausmeister übernehmen.
Ja, im Prinzip.
Aber Cobol ist eine wirklich einfache Sprache. Keine lokalen Variablen, keine Funktionen. Naja, statt der Funktionen macht man Programme, die sich gegenseitig aufrufen (ohne Prüfung, ob die Aufrufparameter richtig sind).
Nun besteht die Application inzwischen 10000 Programmen. Achja, Programme aufzurufen ist so umständlich, daß man viel lieber den Code, den man haben will, per Copy&Paste besorgt.
Der Cobol-Einsteiger kann Cobol nach 2 Tagen, aber die bereits in den 90-er Jahren umgekippte Anwendung zu meistern, das ist seine Aufgabe.Die traumhaften 200€ sind eher für die Verbrecher, die den Scherbenhaufen hinterlassen haben, und aus der Rente geholt werden, weil das System ganz und gar stehengeblieben ist.
-
Cobol macht Spaß. Mache das schon über 20 Jahre und auch hier kann mann mit call und perform wirkungsvoll strukturiert programmieren. Was die Scnittstellen beim Call angeht - dafür verwendet man sogenannte Copy-Books - das sind katalogisierte Code-Schnipsel so wie die .h bei C. Außerdem hat Cobol den Vorteil, dass man sich eben nicht um das ganze Speichergedöns usw kümmern muss, sondern sich auf die Anwendung konzentrieren kann. Und - im Großrechnerumfeld - mit Assembler-Unterprogrammen kann man dann die tollsten Sachen machen, wie dynamisch Dateien im laufenden Programm neu zuordnen usw. Dazu kommt noch, dass die Sprache auch von Nicht-Programmieren gelesen und verstanden werden kann. Zwar nicht im Detail - aber man kann sehen, was eigentlich passiert. Insbesondere, wenn für die Variablen sprechende Namen vergeben werden. 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.
-
Ich bin immer wieder erstaunt, wieviel Halbwissen über Cobol besteht.
Cobol steht für "Co mmon b usiness o riented l anguage".
Es geht bei Cobol NICHT darum irgendwelche 10-dimensionalen Arrays dynamisch mit rekursiv aufgerufenen Funktionen abzuarbeiten.
Es geht um reine Geschäftsanwendungen (wobei mit Cobol durchaus auch Systemprogramme entwickelt werden, da sehr hardwarenah).Was erwartet man also von einer Programmiersprache, die rein business mässig alles abdeckt, wenn man sie heute entwickeln würde?
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 dokumentiertAll das unterstützt Cobol. Cobol wird hauptsächlich auf IBM Maschinen des Z-Systems oder ähnlichen Systemen eingesetzt. https://de.wikipedia.org/wiki/Z_Systems
Vielleicht ein Augenmerk auf die verwendete CPU https://de.wikipedia.org/wiki/Z_Systems#Die_CPU
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 Billionen - natürlich revisionsfähig und daher mit Journalisierung und anderen Mechanismen. Und sowas wollt ihr mit C++ umsetzen? -
es darf gelacht werden....Ach ja - was die Lernkurve für Cobol betrifft: Hier das Cobol Programming Guide der IBM: http://publibfp.boulder.ibm.com/epubs/pdf/igy6pg10.pdf
-
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 dokumentiertLOL
-
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 BillioneWow, 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?
-
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
-
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?
-
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.
-
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...
