Das waren noch Zeiten, als die Phreaks kurze Haare hatten und weisse Hemden mit Krawatte.
Und 'ne dicke Hornbrille uff de Nasen....
Bei uns wurden im Rechenzentrum weiße Kittel getragen.
Hallo Besucher, der Thread wurde 22k mal aufgerufen und enthält 156 Antworten
letzter Beitrag von struuunz am
Die Programmiersprache COBOL
- tilobyte
- Erledigt
-
-
Ich erinnere mich nicht im geringsten an sowas wie "User-Interface" oder Bildschirmmasken, oder wie man das am Großrechner programmiert hätte.
Die Datenverarbeitung war in den meisten Fällen ja halb-interaktiv. Die IBM-Terminals bekamen vom Host eine Eingabemaske, in die die Daten für die aktuelle Transaktion lokal eingetragen wurden. Das ging recht flott, da alles im Terminal passierte. Dann wurden diese lokalen Daten auf Knopfdruck wieder an den Host gesendet. Während der Eingabezeit konnte der Host sich um andere Transaktionen kümmern.
-
Die Datenverarbeitung war in den meisten Fällen ja halb-interaktiv. Die IBM-Terminals bekamen vom Host eine Eingabemaske, in die die Daten für die aktuelle Transaktion lokal eingetragen wurden. Das ging recht flott, da alles im Terminal passierte. Dann wurden diese lokalen Daten auf Knopfdruck wieder an den Host gesendet. Während der Eingabezeit konnte der Host sich um andere Transaktionen kümmern.
Ich erinnere mich an die TIPS, "Transacrtions in progress / sec", die auf dem Hauptterminal der Unisys in den Monitor gebrannt wurden.
An VT100-Emulatoren (für die jüngere DEC?) erinnere ich mich auch, und die Bildchen vom IBM-Emulator kommen mir auch ein bisschen vertraut vor.
Aber dass ich dazu mal irgendwas programmiert hätte... Ne, nix, kein bisschen Erinnerung.
-
joshy Der Tretroller- Vergleich hinkt, wenn hier nur die Geschwindigkeit und Grösse der Massenspeicher bemängelt wird. Und das hat sich am C64 doch extrem verbessert?
Also ist es nicht eher so, das der C64 damals ungeeignet war, jetzt aber wesentlich besser dasteht, wenn es ein modernes COBOL für ihn gäbe, was die neuen Möglichkeiten nutzt?
Was ist denn daran noch Retro, wenn das dann eine SD2IEC oder sonstige Hardwareerweiterungen braucht. Dann kann man das doch gleich auf dem PC oder auf dem Raspi machen.
-
Der Tretroller- Vergleich hinkt, wenn hier nur die Geschwindigkeit und Grösse der Massenspeicher bemängelt wird. Und das hat sich am C64 doch extrem verbessert?
Jeder Vergleich hinkt - der C64 ist ein netter Spielecomputer, nicht mehr. COBOL wird zur Erstellung kommerzieller Programme in Rechenzentren(!) verwendet. Die Progammiersprache ist da nicht ausschlaggebend sondern die Gesamtinfrastruktur aus mächtiger Peripherie und Rechnern mit echten Betriebssystemen. Natürlich kannst Du das nicht mit einem C64 vergleichen.
Also ist es nicht eher so, das der C64 damals ungeeignet war, jetzt aber wesentlich besser dasteht, wenn es ein modernes COBOL für ihn gäbe, was die neuen Möglichkeiten nutzt?
Und nochmal - heute ist jeder Raspi 100x leistungsfähiger wie jeder C64, und trotzdem programmiert den keiner in COBOL und würde auch nicht behaupten, dass man tolle Sachen mit COBOL auf dem Raspi machen kann. Das gehört einfach nicht zusammen.
Wenn Du eine Hochsprache für die Softwareentwicklung für einen C64 benötigst, nimm einen C/C++ Crosscompiler oder irgendwas was auf einem echten Computer ausführbaren 6502 Code erzeugt. COBOL, FORTRAN und ähnliches ist da untauglich.
Der C64 hat sich auch seit 1982 nicht besonders weiterentwickelt - und eigentlich will das auch keiner. Wir lieben die Kiste so wie er ist
-
Der C64 hat sich auch seit 1982 nicht besonders weiterentwickelt - und eigentlich will das auch keiner. Wir lieben die Kiste so wie er ist
YEP ... gibt ja auch noch den C128.
-
Diese Sprache sollten die Grünen lernen.
Wenn die erst mal Coboldisch können, dann klappt auch die Kommunikation mit ihre Kobolde in den Akkus
-
YEP ... gibt ja auch noch den C128.
Ja, mit zwei C1571 ist die Geschwindigkeit erträglich - aber richtig Spass macht das auch nicht. Ist aber deutlich besser, als auf dem C64 - das habe ich selber ausprobiert
Einmal ausprobiert - um genau zu sein. Dann wieder eingelagert.
-
Es kommt tatsächlich darauf an, was man machen möchte. Interaktive Programme in COBOL sehen halt aus wie typische Datenbank-Masken mit etlichen Feldern an festen Bildschirmpositionen. Um das auf einem C64 zu nutzen, benötigt man so etwas wie eine Terminalemulation. Das ist ziemlich sicher nicht Bestandteil der C64-COBOL-Umgebung.
Sinnvoller kann da schon die sequentielle Dateiverarbeitung sein, also lese einen oder mehrere Datensätze aus einer Eingabedatei, tue wasauchimmer damit und gebe die Ergebnisse sequentiell als Datei oder Druckliste wieder aus. Weiter geht es dann mit dem nächsten Datenpaket bis alles verarbeitet ist. Das ist typische kommerzielle EDV. Die Daten könnte man mit einem BASIC-Programm als sequentielle DAtei erzeugt haben.
-
Einmal ausprobiert - um genau zu sein. Dann wieder eingelagert.
Hauptsache man kann es als Echtsystem zeigen ... COBOL 64 auf dem C64. Hat denn jemand zufällig kleine Beispielprogramme, die man mal starten könnte? Habe leider kein Beispielprogramm für den C64 auf die Schnelle ... dann könnte man das mal hier zeigen.
-
joshy Der Tretroller- Vergleich hinkt, wenn hier nur die Geschwindigkeit und Grösse der Massenspeicher bemängelt wird. Und das hat sich am C64 doch extrem verbessert?
Also ist es nicht eher so, das der C64 damals ungeeignet war, jetzt aber wesentlich besser dasteht, wenn es ein modernes COBOL für ihn gäbe, was die neuen Möglichkeiten nutzt?
"Das passt nicht zusammen" und "ist ganz anders" ist natürlich nicht sehr plastisch...
Unsere Unisys hatte keine Bytes, sondern 36-Bit-Worte.
Wo der 64er 65535 Adressen hat, hatte so ein früher Großrechner auch nicht unbedingt mehr. 64K Adressen war sagen wir mal Stand der 60er.
Unterm Strich war der Speicher also doch recht schnell voll. Und das Ding musste nicht nur 1 Programm laufen lassen, sondern kam mit mehreren Programmen verschiedener User gleichzeitig zurecht, die aber nie komplett im Speicher waren.
Und an die Dinger konntest Du dann dutzende Tapes anschließen, die je 1MB die Sekunde liefern konnten.
Wenn ich das so auf C64 übertrage:
- Die großen Steckmodule haben ein bisschen Ähnlichkeit, wenn sie Code nicht direkt ausführen, sondern einzelne Code-Module bei Bedarf rüberkopiert werden. Nur stammen die Code-Schnipsel von ganz verschiedenen Leuten und sind frei im Speicher zu verschieben.
- Ein normaler Loader für die 1541 liest ja einen Sektor, bearbeitet ihn und übermittelt ihn dann an den 64er. Die allermeiste Zeit wartet der 64er auf die Floppy. Das geht GAR nicht!! Da müssen mindesten 5 Floppys dran, damit die CPU ordentlich ausgelastet wird - Von 5 verschiedenen Programmen verschiedener User. Und natürlich noch Extra-Hardware je Floppy am Anschluß, um zu puffern und die Bytes nicht per Code abholen zu müssen.
- Programme wurden auch entladen, während der Operator grad nach den nötigen Tapes sucht. Irgendwer freut sich über den freien Speicher.
- Es gibt kein Bildschirm-RAM, keine Tastatur, keinen direkten Kontakt mit dem User. Stattdessen aber schon hunderte oder tausende Terminals. Ich erinnere mich an ein Gerät mit Namen "Konzentrator", ein kleiner Großrechner von der Größe einiger Kühltruhen. Das Ding hat ankommende Daten der Terminals aufbereitet, damit der eigentliche Rechner das Zeug in einem Rutsch gleich wegarbeiten konnte.
- Für die Terminals muss es so eine Art von Winz-html für Textmodus gegeben haben. An den Teil erinnere ich mich nicht mehr, aber ich wette, das wurde wie sequentielle Dateien programmiert.
Dieses ganz andere Umfeld macht sich auch hier und da an der Sprache bemerkbar.
Datensätze fester Länge waren hui, variable Länge war pfui. Ungefähr so wie "BIF-Basic" - Kann man machen, muss man aber nicht.
Falls Du also mit dem 64er in einem Nachtlauf die täglichen Bewegungsdaten (Materialentnahmen, Bestellungen usw.) eines Anlagenbauers durchackern willst, Konten und Materialbestände updaten willst und auch noch die clevere Hardware drumrum hast, dann wird das bestimmt ne gelie Sache mit Cobol.
Aber für heute übliche Programme? struuunz sagt, dass es dafür was gibt, aber ich kann mir nicht vorstellen, dass ich begeistert wäre.
-
Aber es gab ja mdn 2 COBOL für den C64 und ich würde einfach gern wissen, was das Problem bei diesen ist, warum sie für den C64 nicht geeignet sind und warum es sie dann überhaupt gab. Und dann kann man evtl. überlegen, ob man diese Probleme beseitigen kann.
Da stimme ich dir voll und ganz zu ... die Handbücher sind derart umfangreich, dass man damit sicherlich viel mehr machen kann.
Ich vermute aber mal eher, dass das kaum jemand ausgeschöpft hat ... die tatsächlichen Möglichkeiten der vorhandenen C64/C128-COBOL-Programme.
-
Und hier scheint es schon deutliche Unterschiede zwischen COBOL 64 und COBOl 128 zu geben ...
.COBOL Experten/Expertinnen vor ... was sagt uns diese Gegenüberstellung genau?
Schneller ... besser?
-
Auf einem Raspi programmiert niemand in COBOL, ja egal, man könnte aber trotzdem?
Nein, ich brauche keine Hochsprache um auf einem "echten Computer"(?) Programme für den C64 umwandeln zu lassen. Es interessiert mich einfach der Machbarkeit wegen.
Und die Machbarkeit ist auf dem C64 eben nicht gegeben.
Du kannst vermutlich auf dem C64 irgendwelchen Quellcode, der wie COBOL aussieht, übersetzen oder starten. Mit einem Programm, das sich möglicherweise COBOL-Compiler nennt. Das hat aber mit dem tatschlichen COBOL, wie es damals eingesetzt wurde, überhaupt nichts zu tun.
Weil die COBOL-Umgebung eben nicht nur die Sprache war. Das COBOL-Feeling wird nicht aufkommen. Also was bringt das dann?
-
Bodhi1969 Einerseits gibt es da XFree86, dann gibbet Wayland, MGR gibt's auch und last but not least -> SVGALib
Got me, ich meinte natürlich eine funktionierende GUI für COBOL unter Linux.
-
Bodhi1969 Einerseits gibt es da XFree86, dann gibbet Wayland, MGR gibt's auch und last but not least -> SVGALib
Got me, ich meinte natürlich eine funktionierende GUI für COBOL unter Linux.
Nicht das ich wüßte.
Cobol ist ja nicht so 'in', nä?
Es gibt aber GnuCobol, bzw. OpenCobol -> https://wiki.ubuntuusers.de/OpenCOBOL/
Hat aber keine GUI afaik.
-
Got me, ich meinte natürlich eine funktionierende GUI für COBOL unter Linux.
Visual COBOL von Microfocus ist wohl der Standard, wenn ich das richtig deute. Gibt's für Visual Studio und Eclipse.
