Hello, Guest the thread was called8.1k times and contains 89 replays

last post from 48'er at the

Die Programmiersprache COBOL

  • Ist irgendwie schon witzig: Wenn man eine über 60 Jahre alte Programmiersprache kann, hat man eine gute berufliche Zukunft. :D

    Hat aber irgendwie auch etwas beruhigendes. Es muss nicht immer schneller, weiter und neuer bedeuten.

  • An der TU Wien war Ende der 1980er Anfang der 1990er COBOL noch als Programmiersprache für die Kommerzielle Datenverarbeitung und für zu absolvierende Übungen in Verwendung (ob Pflicht, kann ich nicht mehr sagen).

    Das war gerade zu Zeiten, wo die Objekt-Orientierung in aller Munde war und als Heilbringer der IT galt, während man COBOL schon damals als Relikt ansah, aber - wie hier schon immer wieder gesagt - in etlichen kommerziellen Anwendungen vorhanden war oder überlebt hat.

    Ich kann mich nicht mehr so genau an unser Projekt erinnern, aber es ging um Flug-Management und es war insofern recht nett, weil die Datenbank-Anbindung einfach implizit in die Sprache eingebunden war. Das könnte der Reiz bei der Sache gewesen sein, dass alles mit der Datenbank mehr oder weniger "schön" (ohne extra Aufwand) zugänglich war.

    Mein Kollege von der Projektgruppe ging dann in de Universitätsadministration und dort war dann auch alles COBOL-lastig (er hatte da dann seinen Spaß). :D

  • Mein IT-Prof im abgebrochenen E-Technik-Studium (WS/1995 war ich so pleite, dass ich mir nicht einmal mehr den Sprit leisten konnte um an der FH die Exmatrikulation zu beantragen.) sagte immer:


    "Ihr werdet euch noch am mich erinnern: FORTRAN 77 ist die Zukunft der Programmiersprachen!"


    Er lag wohl falsch ...

    Aber COBOL hat er uns auch in ein oder 2 Vorlesungen vorgestellt und als "Unsinn" hingestellt.

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

  • Ich "durfte" COBOL neben Pascal in der Ausbildung zum Datenverarbeitungskaufmann lernen.

    Das war 1991 so ziemlich der einzige Lehrberuf, der mit IT zu tun hatte.

    ...

    Das war einige Jahre, nachdem ich mir BASIC und 6502 Assembler im "Selbststudium" beigebracht hatte.

    Bei mir praktisch das Gleiche. Ich bin DVK'92, mit Pascal aus der Schule und Basic/Assembler von zu Hause.

    Die Berufsschule war glaub ich ohne PC, aber in der Werksschule und auf Arbeit waren verschiedenste Rechner verfügbar.

    Kann sein, dass wir auch mal was sortiert haben, aber wichtigstes Thema war bei uns "Gruppenwechsel" und Druckaufbereitung.


    Das war ne abgefahrene Mischung an Rechnern, die wir damals life gesehen haben.

    Da war die alte Unisys/Sperry Univac, wo der Tape-Controller die Größe eines Kleiderschranks hatte und dessen Technik noch auf dem Stand der "Nagelbretter" war, mit tausenden, handverlöteten Leitungen. Das hat echt Spaß gemacht, Magnetbänder aus dem Klima-Lager zu holen und in die Lesegeräte einzulegen.


    Daneben stand eine damals flammneue Maschine von DEC mit 6 oder 12 Alpha-Prozessoren.

    Den IBM-Mainframe mit Wasserkühlung haben wir nur im Rahmen einer Führung kennengelernt, und dann war da noch so ein "Janus", in dem 2 Prozessoren alle Schritte parallel durchgeführt haben, deren Ergebnisse zur Sicherheit ständig verglichen wurden.


    Die Kettendrucker aus den 60er/70ern hatten auch eher die Größe eines Smart, daneben ein elektrostatischer Farbplotter, den wir in der Schule als "Prototyp-Phase" kennengelernt haben und der imho der Vorläufer eines Farb-Laserdruckers war.


    Und auf Arbeit haben wir in Access 1.0 eine Anwendung programmiert.

    Dann besser Cobol...X/

  • Ich, Baujahr 1959 (oder soll ich sagen 59, passt irgendwie besser zum Y2K-Thema) habe einen nicht unerheblichen Teil meiner Karriere als Programmierer (passt irgendwie auch besser als 'Softwareentwickler') mit COBOL zugebracht. Die Plattform war damals TANDEM, später HP-NonStop. Eigentlich komme ich von BASIC, später FORTRAN (aus dem Mathestudium), ein wenig ALGOL und SIMULA (aus den Informatikvorlesungen, alles auf Lochkarten). Später habe ich mir dann Z80-Assembler und C beigebracht und in der Industrie damit Maschinensteuerungen entwickelt. Nun hatte der Job leider ein Verfallsdatum und ich sah mich gezwungen, als Selbständiger (damals noch mit einem 'st') in der Wirtschaft anzuheuern. Ich hatte gute Ideen, die Probleme des Kunden in C zu lösen, aber gegen 'Wir machen das in COBOL' kam ich nicht an. Also COBOL und Datenbanken lernen... Das PDF-Format war noch nicht erfunden oder zumindest noch nicht verbreitet, so war meine Literatur ein 1000seitiges Referenz-Handbuch in zwei Ordnern, das ausdrücklich nicht zum Erlernen der Sprache gedacht war. Aber was tut man nicht alles für Geld...


    Es gibt einen Grund, warum man so dicke Handbücher für COBOL braucht: Für alle Operationen, die in C oder Java durch irgendwelche Sonderzeichen beschrieben werden, existiert in COBOL ein 'Verb' also ein Befehl. Da kommen einige zusammen. Es sollte sich halt lesen wie eine Geschichte. Der Quelltext mit seinen DIVISIONs, SECTIONs und Kapiteln erinnert tatsächlich an Prosa. Das einzige Satzzeichen, an das ich mich erinnere, ist der Punkt. Aber dass Buchhalter und Manager je einen Blick in den Quellcode ihrer wichtigen Programme geworfen hätten, halte ich für unwahrscheinlich.


    COBOL85 kannte wenigstens schon IF THEN ELSE und COMPUTE. Allerdings sind lokale Variablen und Modularisierung Fremdworte. Viele COBOL-Programme sind große Monoliten. Ich selbst habe auch nur ein einziges COBOL-Programm geschrieben, danach nur noch Kopien davon gemacht. Der Grund ist, dass man eine feste Struktur einhalten muss, um ein gültiges COBOL-Programm zu erstellen. Da schreibt man sich die Finger wund, bevor man in der PROCEDURE DIVISION einen einzigen Befehl kodiert hat. Dazu kommt, dass bei den Kunden, in meinem Fall war das ein Einzelhandels-Filialunternehmen, eine gewisse Struktur der Prgramme vorgegeben ist. Kopieren ist da die einzige sinnvolle Möglichkeit, zu Ergebnissen zu kommen. Da Unterprogramme mit lokalen Datenbereichen genauso komplex zu erstellen sind, wie Hauptprogramme, haben sich die allermeisten Programmierer den Aufwand gespart, daher der Mangel an Modularisierung. Stattdessen werden üblicherweise sehr viele einzelne Programme gebaut, die dann ihren Teil der Datenverarbeitung übernehmen und untereinander über Dateien oder Datenbanken kommunizieren. Die HP-NonStop-Architektur unterstützt darüber hinaus eine Client/Server-Architektur, in der sich die Programme untereinander Messages schicken. Ich habe schon komplexe Anwedungen mit Tausenden einzelner Programme gesehen.


    Bei all dem Lamento, warum hat man sich das angetan? Hinter COBOL (und seinen Seelenverwandten wie der SAP-Prograammierumgebung ABAP) steckt eine bestimmte Denke, die ihren Ursprung in den festen Satzlängen der Lochkarte hat. Daten werden in Datensätzen organisiert, denen eine feste Struktur zugrunde liegt. Diese Struktur wird in den Programmen (und nicht in der Datenbank!) in Feldern fester Länge abgebildet. Aufgabe eines typischen COBOL-Batchprogrammes, also eines für die meist nächtliche Verarbeitung der Daten des Tages, ist, eine große Menge gleichartiger Datensätze einzulesen, zu bearbeiten, und in anderer Schüttung wieder auszuspucken. Das nächste Programm in der Kette übernimmt dann diese Daten und macht ihr Ding damit. Häufig sind noch SORT-Schrittte dazwischen eingestreut. So entsteht immer noch ein Großteil unserer Bankkontobewegungen. Bei interaktiven Programmen erfasst der Sachbearbeiter in einer oder mehreren Masken Daten, die dann wieder in eine feste Struktur gepackt werden und für die Verbeitung an einen Server (also ein COBOL-Programm mit einer Message-Schnittstelle) gesendet werden. Das bearbeitet und speichert dann den Datensatz und liefert in einer Antwortstruktur die Ergebnisse der Verarbeitung oder die angeforderten Daten zurück. Viele dieser Anwendungen sind Jahrzehnte im Einsatz. Und etliche COBOL-Enwickler alter Schule kennen auch nichts anderes.


    Bei einem meiner aktuellen SAP-Projekte ging es darum, eine alte COBOL-Anwendung zu analysieren, um sie in ABAP neu zu implementieren. Die Frage nach der Dokumentation der vorhandenen Anwendung wurde mit 'Frage mal den und den oder schaue in die Programme!' beantwortet. Um überhaupt eine Chance zu haben, habe ich mir dann in Java einen rudimentären COBOL-Parser gebaut, der die kompletten Quelltexte in eine verlinkte HTML-Dokumentation umgewandelt hat. Als ich das dann den bisherigen Entwicklern gezeigt habe, standen die Münder eine ganze Zeit lang offen. :O

  • Ist irgendwie schon witzig: Wenn man eine über 60 Jahre alte Programmiersprache kann, hat man eine gute berufliche Zukunft.

    Das ist gar nicht so selten. Beispiele:


    Unsere Entwickler basteln aktuelle IPv6 IoT Geräte mit 6502 CPU und Contiki :thumbsup:

    Ein moderner 6502 verbraucht mit seinen 3k Transistoren kaum Strom und hat dank Contiki einen TCP/IP Stack.


    Die NASA braucht immer noch FORTRAN Programmierer: NASA and the Future of Fortran


    Ich selbst betreue noch 486er PCs mit Multi-IO-Karten in ISA-Slots, an denen irgendwelche kriegswichtigen Testgeräte hängen, mit denen aktuelle medizinische Geräte getestet werden. Da läuft noch DOS 6.22 und ein Test-Programm, welches Anfang der 90er mal in Pascal geschrieben wurde. Ja, man könnte das mal neu machen, aber die Rezertifizierung wäre zu teuer :rolleyes:


    Gerade in der Industrie sind diese alten System kaum tot zu kriegen.

  • Moin,


    kennt jemand den Moshix YT channel? Das ist ein Mainframe Channel, zumeist über Hercules (IBM s/360, z Series Emulator) und dem freien MVS 3.8j aus den 80ern. Da geht 's auch das eine oder andere Mal um COBOL und wie es sich unter MVS so programmieren lässt. 8bit show and tell hat hier, analog zur eingehenden Frage, auch ein schönes Video mit COBOL & c64 Bezug :-)


    Leider ist beides auf Englisch, aber wirklich interessant.

  • Wir hatten keine Computer in der Schule und Programmieren hieß bei uns:

    - Wir sollten Zahlen mit Bubblesort sortieren.

    - Man nehme ein DIN-A4 Blatt und zeichne ein PAP mit Hilfe einer Schablone.

    - Danach erst kommt das Codieren: Man setzt das PAP Schritt für Schritt in Code um (auch auf Papier).

    Das ist beim Fachinformatiker Fa. Anwendungsentwicklung heute nicht viel anders. Bei den Grundlagen wird erst programmiert und das hat nix mit einem Computer zu tun, sondern erst wenn alles ausgetüftelt ist und davon ein Fluss- oder Struktogramm oder Pseudocode vorliegt geht es an das Codieren was dann nur noch ein runter schreiben ist von dem was man sich vorher auf Papier ausgedacht hat. :thumbsup:

  • Aber bei dem geringen Speicher der damaligen Rechner, war das wirklich so sinnvoll?

    Cobol ist eine Hochsprache und wir compiliert. Ausgeführt wird der Maschinencode. Entscheidend für dessen Qualität ist der Compiler.


    Und wie schnell ist die Sprache überhaupt?

    Eine Sprache hat keine Geschwindigkeit - ausschlaggebend ist der Sprechende. In dem Fall der Computer.

    In der Zeitschrift für Assyriologie übersetzte H. Zimmern 1896 einen fast 3000 Jahre alten Text, der in den Ruinen der Bibliothek des Assurbanipal in Ninive gefunden wurde, aus der Keilschrift ins Deutsche. Auf dem Tontäfelchen hatte der Umanu (Weisheitsvermittler) Shaggil-kinam-ubib notiert:

    ,Schaust du hin, so sind die Menschen insgesamt blöde.‘

    Das fasst im Prinzip alles ganz gut zusammen.“

    Edited once, last by joshy ().

  • Hat denn jemand mal COBOL am C64 ausprobiert?

    Es gibt eine Version des Nevada COBOL für den C64 - allerdings nur unter CP/M. Der C64 muss also mit einer Z80 Karte aufgerüstet sein. Da CP/M und der COBOL Compiler diskettenorientiert läuft, mach das mit den C64 Laufwerken keinen Spass. Es ist lediglich ein Proof of Concept und keine brauchbare Lösung.

    Esw gab noch einen COBOL Compiler für den C64 von Abacus Software. Der war aber auch nur sehr eingeschänkt zum COBOL lernen zu verwenden. Was produktives kann man damit nicht machen.

    In der Zeitschrift für Assyriologie übersetzte H. Zimmern 1896 einen fast 3000 Jahre alten Text, der in den Ruinen der Bibliothek des Assurbanipal in Ninive gefunden wurde, aus der Keilschrift ins Deutsche. Auf dem Tontäfelchen hatte der Umanu (Weisheitsvermittler) Shaggil-kinam-ubib notiert:

    ,Schaust du hin, so sind die Menschen insgesamt blöde.‘

    Das fasst im Prinzip alles ganz gut zusammen.“

  • Bei den Grundlagen wird erst programmiert und das hat nix mit einem Computer zu tun, sondern erst wenn alles ausgetüftelt ist und davon ein Fluss- oder Struktogramm oder Pseudocode vorliegt geht es an das Codieren was dann nur noch ein runter schreiben ist von dem was man sich vorher auf Papier ausgedacht hat.

    Wie man es richtig macht, wissen wir alle - oder sollten es zumindest wissen ;)


    Ich habe mal von einem entfernten Bekannten das Gerücht gehört, dass der Freund einer Nachbarin in einer Firma arbeitet, in der das so läuft:

    - Es wird einfach darauf los programmiert. Kein Struktogramm, kein Design Pattern - einfach loslegen.

    - Dokumentation wird überbewertet. Der Code ist Dokumentation genug.

    - Richtlinien für Variablennamen existieren nicht. Es reichen einzelne Buchstaben: int a = 50, b = 80;

    - Versionsverwaltung bedeutet, das man Ende der Woche den Code in ein datiertes Zip-File packt.

    - Unit Tests und Integration Tests machen andere Firmen auch nicht. Der Praktikant hat aber Grenzfälle für Eingaben manuell getestet. Das reicht.

    - Verschlüsselung lassen wir weg. Wir schauen erst mal, das es so läuft - vielleicht später, wenn dann noch Zeit ist.

    - Wichtige Fixes werden im Live-Code auf der Production-Maschine gemacht, weil es schnell gehen muss.

    - Input Sanitization brauchen wir nicht. Das läuft nur im LAN. Da gibt es keine Angriffe.

    - it compiles, let's ship it ...


    Nicht auszudenken, wie unsere Welt aussähe, in der Menschen - ohne formale Qualifikation - auf diese Weise Code erschüfen, der dann in Endgeräten liefe, die Dinge in der wirklichen Welt messen, steuern oder regeln täten ...


    Wie gesagt, hab' ich gehört ...

  • So oder so ähnlich habe ich das leider in der Praxis erleben dürfen. Als wäre man im Hollywood Streifen wo Programmieren bedeutet dass die die ganze Zeit in die Tasten hauen und als wenn Programmieren wirklich nur das Codieren wäre. Ich verbringe die meiste Zeit damit herauszufinden warum etwas nicht klappt wie ich es mir vorgestellt habe.

  • Ja dann will ich auch mal,


    ich habe Cobol in meiner Ausbildung gelernt und später in meinem Job ein wenig damit zutun gehabt.


    Allerdings mochte ich in Gegensatz zu den meisten anderen hier mit Cobol zu programmieren und das genau aus dem Gründen warum hier viele es hassten. Cobol muß sich strickt an Vorgaben halten (Bsp. Deklarationteil), natürlich ist sowas nervig aber wenn man Quellcodes anderer Programmierer lesen muß, ist das ein netter Vorteil. Erst im Cobol habe ich gelernt vernünftig strukturiert zu Programmieren, weil einem die Sprache dazu zwingt, allerdings fördert das auch die Lesbarkeit.


    Cobol war eine kaufm. Sprache und hatte ihren Einsatzbereich, so schlecht kann Cobol dann nicht sein wenn es sich solang gehalten hat 🙂.


    Übrigends ich hab mal zum Spaß ein Spiel während meiner Ausbildung in Cobol geschrieben, wenn Interesse besteht suche ich das mal raus, ich müsste es irgendwo noch haben.