Diskussion:COBOL

Zum Archiv

Wie wird ein Archiv angelegt?

Automatische Archivierung

Auf dieser Seite werden Abschnitte halbmonatlich automatisch archiviert, wenn sie mit {{Erledigt|1=--~~~~}} markiert sind. Um die Diskussionsseite nicht komplett zu leeren, verbleibt mindestens ein Abschnitt.

Bedeutung von COBOL heute

M.E. wird hier die heutige Bedeutung von COBOL drastisch übertrieben. Auf dem TIOBE Index steht COBOL mit 0,5% Marktanteil auf Platz 27. RedMonk listet COBOL noch nicht einmal mehr. In den letzten 12 Jahren ist kein einziges Buch über COBOL erschienen und meine Frau (die leider noch in COBOL ausgebildet wurde) hat auf dem Arbeitsmarkt keine einzige Stelle für COBOL Entwickler gefunden. Das beweist m.E. eindeutig dass COBOL alles andere als "bis heute eine der am weitesten verbreiteten für kaufmännische Anwendungen" ist. AlgorithMan (Diskussion) 15:05, 5. Sep. 2013 (CEST)

Die Aussage im ersten Abschnitt, dass COBOL Zitat „bis heute verwendet“ wird, stammt aus dem Jahr 2006. Stimmt das noch? – Gebu (Diskussion) 05:22, 15. Aug. 2023 (CEST)

Selbstverständlich; zB Martin Reusch: COBOL 2022 – So relevant wie nie?! In: it-daily.net. 11. April 2022; abgerufen am 15. August 2023.  --rolf_acker (Diskussion · Beiträge) 09:40, 15. Aug. 2023 (CEST)

Cobol standards - umstrukturierung

Wenn ich mich recht erinnere gab es von Cobol verschiedene Standards, die nach ihrem Erscheinungsjahr benannt waren: Cobol 75, Cobol 86 und Cobol 9?. Allerdings wurde auch jahrelang nachdem ein neuer Standard veroeffentlicht und implementiert wurde, immernoch nach altem Stanard entwickelt.

Ich habe den Artikel recht aggressiv umstrukturiert. Erweitert werden müsste er noch werden in dem Abschnitt über die Data Division( das mit dem Stufennummern ist doch sehr Cobol-typisch)und in der Proce müsste noch dargestellt werden, wie man Cobol-Code strukturiert (Perform-Schleifen, Perform, Call). Die Compiler-Liste habe ich nach hinten geschoben. Dort sollten Hersteller und Zielpattform genannt werden; ich kenne leider nur die IBM-Welt ganz gut (VS Cobol II ist out).Hpb 16:21, 22. Aug 2004 (CEST)

Bis jetzt (Juli 2016) hat noch kein Hersteller eines Compilers "HIER" geschriehen und verkündet, er habe eine Implementierung des 2002-er Standards. Da der 2014-er Standard sich dadurch auszeichnet, das er Sprachelemente, die im 2002-er Standard verpflichtend sind, für optional erklärt, dürfte meiner Meinung nach der 2014-er wohl eher implementiert werden - wenn überhaupt. 19.07.2016 (nicht signierter Beitrag von 217.91.39.183 (Diskussion) 21:58, 19. Jul 2016 (CEST))

Stufennummern

Ich habe das jetzt schon mal aufgebohrt und werde das Thema nach und nach ergänzen...Lang leben die Dinosaurier (ABAP ist auch nur COBOL...) --Albu 19:51, 14. Sep 2004 (CEST)

Data Division

Ich würde das nicht allzusehr "aufbohren". Es soll schließlich nur ein enzyklopädischer ARtikel über COBOL sein, und keine vollständige Darstellung der Sprache. Ich hatte da andere Ideen und werde die mal umsetzen.

Auch denke ich, daß es richtig das traditionlelle Referenzformat von 80 Zeichen ist, weil a) der aktuelle Standard das alte Format freigeben hat, und b) weil auch andere Compiler vorher schon ein ganz freies Format ermöglichten.

M.W. hatte ich das z.B. schon vor 10 Jahren in dem UCOB nach COBOL-85 von Unisys, daß der rechte Rand freigegeben war, und der Fujitsu-Compiler 3.0, den ich hier unter Windows am Laufen habe, kann auch das freie Format.

mfG,

--L.Willms 18:07, 15. Sep 2004 (CEST)

In der DATA Division gehts um DEFINITIONEN und die haben mit 80 Zeichen NICHTS zu tun. In der Host-Umgebung ist die Code-Zeile ausschliesslich 80 Zeichen.

--Albu 16:17, 17. Sep 2004 (CEST)

Zum Stand heute

Zum Stand heute habe ich aus dem Web ein paar Zahlen recherchiert:

Im Jahr 1999 war etwa die Hälfte aller für den Geschäftserfolg eines Unternehmens kritischen Anwendungen in COBOL geschrieben. 2004-2005 werden 15% der neu geschriebenen Softwareanwendungen für Unternehmen in COBOL codiert (da sind 5 Milliarden Zeilen pro Jahr). 2002 gab es weltweit ungefähr zwei Millionen COBOL-Programmierer, im Vergleich zu zwei Million Java-Programmierern und einer Million C++ Programmierer. (Alle Zahlen Schätzungen laut Gartner Group). Vielleicht kann man das zur Verdeutlichung der Bedeutung von COBOL auch heute noch einarbeiten. --UlrichJ 17:45, 10. Mär 2005 (CET)

die 1 mio c++ programmierer klingen mehr als unglaubwürdig. auch 2002 schon dürfte diese angabe viel zu gering sein. und doppelt soviel java- wie c++ programmierer ist einfach eine lachhafte behauptung. 100mio c++ programmierer weltweit klänge schon wahrscheinlicher. --LaLa 11:00, 20.März 2008

Also wohl die nicht am häufigsten verbreitete Programmiersprache? Und was sagt schon die Zahl der Programmierer? Wieviele arbeiten davon tatsächlich und wieviele Zeilen schreiben die? --House1630 23:29, 19. Jan. 2012 (CET)

XCOBOL

Ich arbeite derzeit in einem größeren Projekt, in dem ganz massiv XCOBOL eingesetzt wird. Leider habe ich in diesem Artikel nicht einmal den Namen dieser (Präprozessor-) Variante von COBOL gefunden, durch die ja immerhin Konzepte wie Kapselung und Vererbung eingeführt werden. Weiß hier jemand mehr darüber? Und sollte man XCOBOL im Artikel nicht zumindest erwähnen? --Kai 14:01, 23. Aug 2006 (CEST)

Datentypen?

Könnte jemand etwas über die in COBOL verfügbaren Datentypen ergänzen? So soll es in COBOL Datentypen geben, die reelle Zahlen ohne Rundungsfehler abbilden. Stimmt das? Danke! 193.141.139.222 18:50, 27. Sep. 2007 (CEST)

Ja, das stimmt so. Cobol arbeitet bei PIC 9-Feldern mit sogenanntem Binary-Coded Decimal. Früher hatten Hostrechner teilweise sogar BCD-Rechenwerke, heutige Rechner haben sowas nicht mehr, da wird das Rechenverhalten entsprechend emuliert. Dabei tauchen dann die typischen numerischen Fehler beim Hin- und herrechnen zwischen Dezimal- und Binärsystem nicht auf (wie jüngst mal wieder in Excel 2007 erlebt). Und tatsächlich taucht dazu nichts im Cobol-Artikel auf. Das sollte ergänzt werden. --Markus Großmann 19:17, 27. Sep. 2007 (CEST)

Wie bildet man denn die reelle Zahl wurzel(2) ohne Rundungsfehler ab? --Rat 09:56, 24. Nov. 2011 (CET)

Beispiel "Wertebereich"

Ich habe schon seit etlichen Jahren nichts mehr mit COBOL zu tun gehabt, deshalb frage ich mit aller gebotenen Vorsicht nach, ob man tatsächlich Vereinbarungen auf der Stufennummer 05 nur mit VALUE-Klausel (ohne PIC) vornehmen kann. Wenn ja: Kann mir jemand sagen, was man damit erreicht? Für mich sieht das Beispiel eher so aus, als ob 88 verwendet werden sollte??!??

mfg

PeBe 217.6.249.162 15:27, 14. Okt. 2008 (CEST)

Auch ich bin der Meinung, dass dies in Fehler ist, jedenfalls habe ich sowas in meiner Karriere nie angetroffen.--Flaco LU 11:48, 13. Apr. 2009 (CEST)

Jahr 2000 Problematik

Ich denke, für einen Laien wäre es auch interessant, dass etwas über die Jahr 2000 Problmatik gesagt wird, da dieses Thema damals häuffig als COBOL-Problematik dargestellt wurde (Was für mich natürlich nicht stimmt).

--Flaco LU 11:52, 13. Apr. 2009 (CEST)

Acucobol

Der Anbieter Acucobol ist 2007 von Micro Focus übernommen worden und seither kein selbstständiges Unternehmen mehr. Ich werde den Verwies daher ändern. --Prcom 17:34, 16. Mai 2011 (CEST)

Performance

Cobol-Programmierer führen als pro Cobol Argument oft an, es sei in der Massendatenverarbeitung schneller als alles andere (insbes. Java o.ä.). Und da CPU-Zeit teuer sei, bliebe man bei Cobol. Ist das so? Ist bei Massendatenverarbeitung nicht die IO-Zeit der maßgebliche Zeitfresser? Oder zählt das bei der CPU-Zeit nicht mit? Welche Prozesse in der Massendatenverarbeitung (ich stelle mir da im Wesentlichen das Erzeugen von Kontoauszügen vor) sind so CPU-intensiv, dass sich das bemerkbar machen würde? --Rat 10:03, 24. Nov. 2011 (CET)

Naja, CPU- Zeit, d.h. Rechenzeit brauchst du schon, wenn du nicht nur Kontoauszüge drucken, sondern auch z.B. den Tagessaldo ausrechnen willst. --House1630 23:32, 19. Jan. 2012 (CET)

Was ich an COBOL Programmen gesehen habe, war extremst lahm. Das führe ich darauf zurück, dass man in COBOL kein Multithreading machen kann (sodass die Programmlogik immer für I/O Operationen unterbrochen werden muss) und auf das Fehlen von dynamischer Speicherverwaltung, durch die man immer nur auf Zwischendateien arbeiten kann (Festplatten sind bekanntermaßen 20.000 mal langsamer als der RAM) AlgorithMan (Diskussion) 14:54, 5. Sep. 2013 (CEST)

Auch heute gilt für Cobol Programme,was immer schon gültig war, für Mainframe Programme, Sections sollten nie die 4K Grenze überschreiten. Ausserdem sollte das Programm nicht zu sehr angereichert sein mit unnötigen Feldern, die nur einmal gebraucht werden. Ein gewisses Umdenken sollten die Programmierer schon beherrschen, lieber weniger Felder die gespeichert werden müssen und nur 1 x Mal verwendet werden. Über Performance gibt es noch mehr zu sagen, dafür würde jetzt die Zeit nicht reichen (nicht signierter Beitrag von 194.114.62.126 (Diskussion) 13:12, 30. Mär. 2015 (CEST))

Produkte zur Codeerzeugung

Inwiefern sind denn die genannten Produkte eigentlich bedeutend? Ich denke, Produkte von Unternehmen sollten nur dann genannt werden bzw. sind nur dann bedeutend, wenn sie eine herausragende Stellung auf dem Markt einnehmen. Wenn das belegbar ist, ist es ja gut. Existenz allein aber reicht nicht aus.

Ich denke, mit Produktnennungen muss man sehr vorsichtig sein, denn nennt man eines, kommt sofort jemand und sagt "dann muss man dieses aber auch nennen". Die Grenze zur Werbung ist dann sehr schnell überschritten. Wehret den Anfängen. ʘχ 11:19, 21. Feb. 2012 (CET)

Hallo, ich bin mir da auch nicht ganz sicher. Eigentlich hatte ich an der Stelle nur geändert weil Produkt- und Firmenname falsch geschrieben waren. Da ich selber für Delta arbeite und an der Entwicklung der Generatoren mitarbeite, hatte ich nur korrigiert aber die Änderungen nicht als gesichtet markiert. Es ist allerdings so, dass Generatoren im Cobol-Umfeld eine sehr grosse Rolle spielen. Wir haben einige Kunden, die zehntausende Module und Millionen LOCs generiert haben. Gleiches gilt sicherlich auch für andere Generatorprodukte im Cobol-Umfeld. Codegeneratoren sind im Cobol-Umfeld schon relevant undihre Verwendung sollte IMO schon erwähnt werden. Ob man da einzelne Produkte nennen sollte, möchte ich nicht beurteilen. Da bin ich einfach nicht ganz objektiv. Die genannten Produkte haben aber im DACH-Bereich schon einee entsprechende Relevanz durch die Anzahl der Installationen, durch die Firmen, die sie verwenden und durch die Menge an Code, die damit erzeugt wurde. Martin 22:10, 21. Feb. 2012 (CET)

William Selden

Hat wirklich ein Mann, der im 19. Jhdt. gelebt hat, am Design von COBOL mitgewirkt? --Leonach (Diskussion) 20:04, 19. Feb. 2016 (CET)

Nein, offenbar handelt es sich um eine Namensgleichheit. Ein Lemma für den fraglichen William Seldon existiert bisher nicht, falls jemand dieses mit seinem Wissen füllen möchte, so sollte er auch gleich herausfinden, was für eine Tätigkeit ein "Informtiker" ausübt....--93.233.49.206 18:49, 26. Sep. 2019 (CEST)

Grace Hopper

laut englischer wikipedia war Grace Hopper nicht am Design beteiligt. Was stimmt den jetzt? (nicht signierter Beitrag von 89.12.89.98 (Diskussion) 17:15, 30. Jun. 2020 (CEST))