Die Programmiersprache COBOL

Es gibt 156 Antworten in diesem Thema, welches 31.353 mal aufgerufen wurde. Der letzte Beitrag (1. Februar 2023 um 11:38) ist von struuunz.

  • Also zurück zum Thema.

    Gerne! :smile:

    Also, es ist ja schon eine Weile her, dass ich COBOL programmiert hatte. Beeindruckt hat mich aber die Geschwindigkeit, mit der Daten verarbeitet wurden. Im Prinzip kann man Jackson-Diagramme stur "reinkloppen" und das Ergebnis passt immer, sofern das Design korrekt war. :wink:

    In den 90ern habe ich das gerne gemacht. Heute wäre mir das nicht mehr effektiv genug und zu ineffizient, weil man einfach zu viel schreiben musste. Vorteil war halt, dass man es lesen konnte wie ein Buch, wenn man denn wollte. :D

    Gruß Dirk

  • Der Prof. war zwar alt (schätze gut 60+), aber fähig und konnte seinen Stoff gut rüberbringen.

    Die Klausuren waren Horror, weil bei den handschriftlich zu erstellenden Programmen auch fehlerhafte Einrückungen im Code zu Punktabzug führten.

    COBOL, um zum Thema Etwas beizutragen, hatte ich mir vor 2 Jahren mal im Zusammenhang mit der Idee in die Programmierung zu wechseln, angeschaut.

    Da redeten Alle von einem Mangel an Programmierern die den COBOL Code bei Banken warten, bzw. portieren können.

    Wikipedia, ein Nachmittag in der Uni-Bib in Trier unter strenger Corinna-Folter und ich habe immer noch Bahnhof verstanden.

    Mal eine Frage:

    Gibt es freie COBOL Compiler für Linux, die man zum Antesten verwenden kann ?

    Seit Juli 2019 wieder mit dem Commodore Virus infiziert.

    Aktuell: C64 Reloaded MK2, C64C, C64 Brotkasten Original, C64 Brotkasten in blassgrau, Amiga 500, Amiga 600, Amiga 2000 (Octagon 2008), Amiga 2000 mit PC-XT, VIC20, Commodore 16 mit 64KB Umbau nach ComputeMit Zeitschrift..

  • COBOL, um zum Thema Etwas beizutragen, hatte ich mir vor 2 Jahren mal im Zusammenhang mit der Idee in die Programmierung zu wechseln, angeschaut.

    Da redeten Alle von einem Mangel an Programmierern die den COBOL Code bei Banken warten, bzw. portieren können.

    "In die Programmierung zu wechseln" heisst, du hast vorher nicht programmiert? Also beruflich?

    Dann wäre der Einstieg als Cobol-Programmierer um alte Programme zu verstehen und zu warten aber ziemlich sportlich.

    Oder meintest du "In die Cobol-Programmierung zu wechseln"?

  • Gibt es freie COBOL Compiler für Linux, die man zum Antesten verwenden kann ?

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Anhang zu sehen.

    :)

  • Snoopy Vielen Dank.

    Habe irgendwie falsch gegoogled oder stand sonst wie auf der Leitung...=O

    detlef nee, Programmierung bisher nur SPS und im Hobby Atmel Micros in Assembler bzw. C / C++.

    Sportlich ist untertrieben, aber so besch... wie im Moment der Job ist und wie sich das Entwickelt mit den Handbremsen aus der Ausbildung...

    Da ist COBOL - Lernen einfacher als ohne passende Ersatzteile, passende Parametriersoftware und die 5 Schichten Hierarchie über mir, die alle nur bedingt vom Fach eine Ahnung haben, wahrscheinlich wie Urlaub.

    Seit Juli 2019 wieder mit dem Commodore Virus infiziert.

    Aktuell: C64 Reloaded MK2, C64C, C64 Brotkasten Original, C64 Brotkasten in blassgrau, Amiga 500, Amiga 600, Amiga 2000 (Octagon 2008), Amiga 2000 mit PC-XT, VIC20, Commodore 16 mit 64KB Umbau nach ComputeMit Zeitschrift..

    Einmal editiert, zuletzt von Der_Alte_Bastler (25. Januar 2023 um 18:37)

  • Cobol? Auf dem C64?

    Jaja :smile: Bitte melde dich an, um diesen Link zu sehen. NEVADA COBOL steht hier originalverpackt in der Wohnzimmervitrine. Aber zugegeben, braucht eine CP/M-Karte.

    es wäre schlimm, wenn es wirklich so ist, oder eher traurig?

    Den Sinn verstehe ich auch nicht.

  • Ich habe mir jetzt mein COBOL Buch bringen lassen. Werde mich mal in das Thema einlesen.


    Vielleicht hat ja ein COBOL Experte eine Meinung zum Buch.

    Der Habib ist super als Einführung, erklärt vieles. Danach kommt es eben schwer auf den Dialekt an in dem du entwickeln willst, wenn überhaupt. Es gibt sehr viele Hersteller von COBOL-Compilern, das glaubt man kaum. Alle setzen den Standard nicht vollständig um und bieten eigene Spracherweiterungen.

    Und wer sich wirklich mit COBOL auseinander setzen will unterhält sich mit Captain COBOL: Bitte melde dich an, um diesen Link zu sehen.

    Hört es euch an, lohnt sich, zumindest der Anfang. Im März trinke ich ein Bier mit ihm :biggrin:

  • Zum Thema Literatur kann ich auch noch Bitte melde dich an, um diesen Link zu sehen. empfehlen, auch wenn Stefan sie nun nach über 20 Jahren nicht mehr pflegt.

    Im Moment des Todes verliert Nationalität völlig seine Bedeutung.

    Ist Sie dann nicht jetzt schon obsolet?!

  • Ich habe mir jetzt mein COBOL Buch bringen lassen. Werde mich mal in das Thema einlesen.

    Vielleicht hat ja ein COBOL Experte eine Meinung zum Buch.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Ich hoffe, das Buch war nicht arg teuer, denn es ist auch bei Bitte melde dich an, um diesen Link zu sehen.

    Im Moment des Todes verliert Nationalität völlig seine Bedeutung.

    Ist Sie dann nicht jetzt schon obsolet?!

  • Also Cobol lernt man wirklich recht schnell. Zumindest die Syntax und den doch eher eingeschränkten Befehlsumfang. Also das stellt einem glaube nicht so vor Probleme.

    Viel spannender und vor allem wichtiger: Wie programmiere ich in Cobol sauber, effizient und vor allem wartungsfreundlich? Da sollte man sich von an fang an auf Programmierrichtlinien einigen. (oder die von der Firma nehmen...) In meinem Berufsalltag hab ich schon so einiges an GRAUMSAMEN Cobolcode gesehen. Von generierten Code von irgendwelcher Kaufsoftware bis hin zu undokumentierten hin und her springen mit GOTO (GOTO ist im Cobol ein FREVEL und sollte mit Nippeldreher bestraft werden. Ein gute Cobolentwickler nutzt nie auch nur einmal im Leben ein GOTO)

    Sections sollten nicht zu lang werden. Code niemals in Copys auslagern. IFs nicht zu sehr verschachteln, "Schalter" (88er Stufen) für Steuerung verwenden, keine Literale im Code, ... es gibt vieles was man beachten muss. Das bekommt man aber in paar Monaten schnell zusammen.

    Interessant ist auch das Zusammenspiel mit Datenbanken. DB2 z.B. ist recht einfach. Wenn man aber mit dem altertümlichen IMS-DB in Berührung kommt, wird es spannend. Je nach Komplexität der Datenbank (Segmente, Keys, ...) kann das schon richtig aufwendig werden.

    Buchempfehlung kann ich da überhaupt keine geben. Da sind eher Workshops viel besser geeignet das zu lernen. Da Erfahrungsaustausch und das Lesen von Beispielprogrammen in Gruppen + Erklärung viel besser ist.

    Leider wird in meinem Arbeitsleben Cobol immer weniger :( Unser Mainframe soll abgeschafft werden und ich säge mit der Java-Umsetzung alter IMS-Dialoge gerade am eigenem, geliebten Ast.

    Bitte melde dich an, um diesen Link zu sehen.

    Einmal editiert, zuletzt von struuunz (27. Januar 2023 um 10:51)

  • Also Cobol lernt man wirklich recht schnell. Zumindest die Syntax und den doch eher eingeschränkten Befehlsumfang. Also das stellt einem glaube nicht so vor Probleme.

    Viel spannender und vor allem wichtiger: Wie programmiere ich in Cobol sauber, effizient und vor allem wartungsfreundlich? Da sollte man sich von an fang an auf Programmierrichtlinien einigen. (oder die von der Firma nehmen...) In meinem Berufsalltag hab ich schon so einiges an GRAUMSAMEN Cobolcode gesehen. Von generierten Code von irgendwelcher Kaufsoftware bis hin zu undokumentierten hin und her springen mit GOTO (GOTO ist im Cobol ein FREVEL und sollte mit Nippeldreher bestraft werden. Ein gute Cobolentwickler nutzt nie auch nur einmal im Leben ein GOTO)

    Eigentlich gilt das ja mehr oder weniger für alle Programmiersprachen. Klar, der Befehlsumfang bei C# und Java ist sicher größer als bei Cobol. Und Libraries sind sehr umfangreich. Aber das ist eigenlich nie das Hauptproblem.

    Ein gute Cobolentwickler nutzt nie auch nur einmal im Leben ein GOTO

    Schön wenn das geht. Das hätte ich jetzt in Cobol gar nicht erwartet.

  • Schön wenn das geht. Das hätte ich jetzt in Cobol gar nicht erwartet.

    Das geht wunderbar, nur muss man sich dann halt wirklich paar Gedanken vorab machen: wie ist mein Fehlerhandling z.B. Hier hat man dann oft ein GOTO in nicht so schön geschriebenen Programmen. Gerade das Thema Fehlerhandling ist ein sehr spannendes Gebiet in Cobol.

    Ich habe in 20 Jahren Cobolentwicklung noch nie auch nur ein GOTO genutzt. Aber dafür schon hunderte aus alten Programmen entfernt. :D

    Eigentlich gilt das ja mehr oder weniger für alle Programmiersprachen. Klar, der Befehlsumfang bei C# und Java ist sicher größer als bei Cobol. Und Libraries sind sehr umfangreich. Aber das ist eigenlich nie das Hauptproblem.

    Ja das ist natürlich bei allen Programmiersprachen von Vorteil. Nur ist Cobol ja so "begrenzt" das man dort sehr viel in einem Workshop abarbeiten kann. Java z.B. ist gigantisch mit seinen unzähligen möglichkeiten und Frameworks. Da wird es unmöglich einen umfassenden Workshop zu gestalten.

  • Ich hoffe, das Buch war nicht arg teuer, denn es ist auch bei Bitte melde dich an, um diesen Link zu sehen.

    Ui, cool. Digitales Backup.:thumbsup:

    Das Buch befindet sich seit über 25 Jahren in meinem Fundus. Hat mich damals nichts gekostet.

  • Ich habe in 20 Jahren Cobolentwicklung noch nie auch nur ein GOTO genutzt. Aber dafür schon hunderte aus alten Programmen entfernt. :D

    Schön, da kennt sich noch einer aus, freut mich. Am eigenen Mainframe Ast müssen leider zur Zeit so einige sägen. So ist das eben wenn das Management nur in Kosten und Einsparungen denkt.

    Schlimmer als der Goto ist in COBOL übrigens der Alter-Befehl: '

    The ALTER statement changes the transfer point specified
    in a GO TO statement.'

    Sprich: Ich kann spontan im Programmlauf das Sprungziel meiner Gotos ändern. Viel Spaß beim Verstehen dieses COdes :wink:

  • Puh... ALTER ist mir zum glück noch nicht unter gekommen! Mit so "tollen" Programmierungen kann man wohl Arbeitsplatzsicherung betreiben. Das dann noch zu verstehen, wenn es ein anderer geschrieben hat ist fast unmöglich.

    Ob Kosten eingespart werden? DAS mag ich doch sehr bezweifeln. Wenn man den Mainframe so einsetzt das seien Stärken genutzt werden und das moderne Umfeld anbindet, ist das nach wie vor ein super Arbeitstier mit viel Potential.