-
Ich habe in 20 Jahren Cobolentwicklung noch nie auch nur ein GOTO genutzt. Aber dafür schon hunderte aus alten Programmen entfernt. 
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 
-
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: https://developer.ibm.com/podc…-talks/016-captain-cobol/
Hört es euch an, lohnt sich, zumindest der Anfang. Im März trinke ich ein Bier mit ihm
-
Jaja 
https://www.c64-wiki.de/wiki/COBOL 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.
-
Was auch immer du da in Cobol laufen hast, ein guter Rat wäre alles umstellen auf C, nicht auf C++, sondern auf C. C hat damals schon Cobol den Rang abgelaufen und alles was in Cobol geht, geht auch in C, aber C ist halt stabiler. Cobol war und ist einfach eine Einbahnstraße.
Bitte zeige mir eine Versicherung oder eine Bank die ihre Kernsysteme in C entwickelt. Wie kommst du darauf?
Ich kann dir versichern, dass viele der Geldautomaten letztes Jahr noch WindowsXP in der Embedded Version benutzten.
Ich kann dir versichern das es nicht das Windows auf dem Geldautomaten ist der nachher die Auszahlung auf deinem Konto bucht. Das einzige was der Geldautomat macht ist das Backend um Erlaubnis zu fragen. Alles andere, Transaktionslogik, Transaktionssicherheit, Datenhaltung, ... passiert auf ganz anderen Systemen. Und ja, zum weitaus größten Teil in COBOL!
Aber wie hier in einem anderen Thead richtig geschrieben wurde, entsteht die Komplexität durch die Applikation. Und die Einarbeitung ist in einer Woche nicht erledigt.
So ist es. COBOL lesen und schreiben geht in einer Woche. Zu lernen wie man performante, resiliente und zuverlässige Anwendungen in COBOL schreibt dauert annähernd so lange wie überall sonst.
-
Aber ihr müsst zugeben, Cobol ist schon nen hartes Stück.
Ich habe zwar Lochkartenprogrammierung nicht mehr kennen gelernt, aber Cobol soll da sehr nah dran gewesen sein..
Vielleicht mal hier lesen: https://de.wikipedia.org/wiki/COBOL
Ich verantworte die Entwicklunglandschaft auf einem IBM System z Mainframe mit knapp 15000 Programmen und gut 50 Entwicklern. Bei der Sprache ist der Name halt Programm: „Common Business Oriented Language“, wer damit Spiele oder Oberflächen entwickeln will ist da an die falsche Sprache geraten. Umgekehrt würde ich keinen Entwickler einstellen der COBOL nicht in einer Woche versteht
Übrigens passieren an vielen Stellen auch heute noch Neuentwicklungen in COBOL, es entstehen Webservices in COBOL, wer am Automaten Geld abhebt oder in der Tanke mit der Karte zahlt kann davon ausgehen das irgendwo COBOL im Spiel ist, Versicherungspolicen ebenso.
Also gebt es euch ruhig mal Und übrigens, wer COBOL beherrscht, verdient auch gut.
-
-
Ich bin beruflich verantwortlich für die Qualität von ca 38 Mio LoC COBOL. COBOL ist 60 Jahre alt, ja. Aber wenn man sich mal informiert wieviel % aller Finanztransaktionen weltweit über COBOL-Programme abgewickelt wird ist das eindrucksvoll. Vergleicht man die Performance solcher Masssenverarbeitungen mit derselben Funktionalität entwickelt in Java, wird Java den kürzeren ziehen. COBOL wird weiterhin laufend modernisiert, beherrscht schon lange XML und auch JSON.
Dennoch hat natürlich auch jede andere Sprache ihre Berechtigung, aber ich werde niemals darauf wetten ob COBOL oder Java zuerst das zeitliche segnet.
Und ja, finanziell lohnt es sich in diesem Bereich zu arbeiten, aber es macht auch noch höllisch Spaß.
Falls sich jemand vertiefen will:
https://community.ibm.com/comm…should-we-still-use-cobol
https://www.jdoodle.com/execute-cobol-online/
-
Leute anstatt hier über die Schreibweise zu meckern solltet ihr mal daran denken das es auch Menschen gibt die der Deutschen Sprache nicht mächtig sind oder es sich um einen Legastheniker handelt.
Sowas finde ich ja echt geil. In jeder Sprache gibt es Satuzeichen, der Punkt wird z.B. immer gleich verwendet. Und Jegastheniker vergessen auch selten Satzzeichen!
-
Momentan habe ich aber nur Sachen der gleichen LW Qualität (von 2 LW, die gleich gut den Job machen) auf der HD, wo es also nicht so offensichtlich ist und das eine höchstens etwas dünner oder wie auch immer 'rüberkommt als das andere LW.
Das ist ja mal total geil, das heißt das Medium Festplatte verfälscht den Klang der Musik nicht?
Danke für den Hinweis, ab sofort bestelle ich meine ganze Musik nur noch auf Festplatten
-
Genau. Schau einfach welcher der Chips das älteste Herstellungsdatum trägt: 4585 = 45.Kalenderwoche 1985.
Das ergibt dann ein vages Herstellungsdatum, also wäre dieser C64 nicht älter als Oktober 1985. SID, VIC, CPU und CIA würd ich nicht annehmen da diese Chips ja für Defekte bekannt sind und daher nicht immer die Orginalen drin stecken.
mfg
Man sollte vielleicht eher nach dem neuesten Chip dadrin gehen, nicht nach dem ältesten
Zumindest in original versiegelten.
-
Erstmal vielen Dank für die schnelle Antwort, ich bin begeistert.
Und du konntest mein Problem auch sofort lösen. Ich habe immer nur T-R versucht, nicht T-RA. Ist aber natürlich logisch das man, wenn es T-WA und T-WB hat, dasselbe auch für T-R gilt.
Danke nochmal
-
So, nach fast einem Jahr muss ich hier mal wieder einsteigen.
Ich habe mir eine Batterie für mein arm2iec besorgt und die aktuellste nightly aufgespielt: 1.0.0alpha0-68
Wenn ich nun T-W oder T-R sage lande ich leider immer auf 30,SYNTAX ERROR, was angeblich bedeutet das ich keine RTC habe.
Mein LPC-Board ist: LPC1769 Rev B.
Die nightly-Builds sind ja mit RTC Unterstützung gewandelt wenn ich die config richtig verstehe. Hat mir jemand einen Tipp oder habe ich dummer weise eine defekte RTC?
-
Unter Windows hatte ich öfters mal Robocopy verwendet, das klappt super, für Linux fällt mir grad keins ein. Evtl mit
- nc -avx --delete --progress Quellverzeichnis/ Zielverzeichnis
?
nc? Von deinen Parametern her meinst du rsync, das kenne ich so schon.
Die Probleme die ich habe sind ja eigentlich:
- Es kann sich auf beiden Seiten was geändert haben, Dafür ist ja eigentlich Unison super, aber
- wenn sich ein d64-Image am SD2IEC ändert ist das Änderungsdatum irgendwas altes, also älter als das auf meinem Rechner und wird deshalb überschrieben. Folge: Highscores sind wieder weg 
-
Mich würde mal interessieren wie Ihr eure SD-Karten so verwaltet.
Ich habe die Dateistruktur wie ich Sie auf der SD-Karte habe auch auf dem Rechner, so kann ich am Rechner zum Beispiel schon mal Dateien ergänzen wenn ich die SD-Karte gar nicht da habe. Umgekehrt kann ich Änderungen auf der SD-Karte auch zurück auf den Rechner syncen, z.B. Savegames, Highscores, sehr selten auch mal was programmiertes
Allerdings habe ich noch nicht die perfekte Lösung gefunden. Was nutzt ihr und wo habt ihr noch Probleme?
Ich muss dazusagen ich nutze Linux und habe schon mit rsync, Unison, find & cp, ... gespielt und alle möglichen Skripte gebaut, aber nichts istt so ganz wie ich es gerne hätte.
-
*grmpf* Mein Webspace ist seit seiner Erstellung 2007 1:1 so online, und das bleibt auch so *sigh*
Ah ja, dann bist du Besitzer von Drop-box und Tinyurl? Cool
-
Spwas, stimmt. Du hast PN.
-
-
Was spricht eigentlich, außer dem Preis, gegen diese Wärmeleitfolie ?
Die setze ich überall ein und bin super zufrieden.
-
Manche Systeme können den Powerknopf tatsächlich abfragen:
The BeOS programmer's guide covers two functions IsComputerOn (returns 1.0 if computer is on, unspecified otherwise) and IsComputerOnFire
(returns temperature if mainboard has flames coming from it,
unspecified otherwise). It's right there in the printed version (though I
quote from memory).
(Quelle )
-
Hast du einen CMOS Z80 Anstelle genommen?
Ist scheinbar ein NMOS, kein CMOS. Hab bei Reichelt bestellt, da wirds aus der Artikelbeschreibung nicht ganz klar, aber mit Aufdruck und Datenblatt wars dann doch ein NMOS.
Glückwunsch! Wäre toll, wenn Du uns ein bischen teilhaben lässt, an Deinen Experimenten mit CP/M auf dem cevi.
Werde ich tun. Soweit ich bisher geschaut habe gibts da draußen sowieso sehr sehr wenig zu Nevada COBOL aufm C64.
