Diskussion:Job Control Language

Skriptsprache

Hallo,
ich bin der Meinung, dass die JCL nicht zu den Skriptsprachen zählt.
Skriptsprachen werden als Programmiersprachen angesehen. Die JCL ist eine Folge von Informationen und Steueranweisungen an das Betriebssystem.
(s. a. G. D. Brown zOS/JCL Kapitel 1.2)
--McMlxx 11:49, 6. Okt. 2011 (CEST)

Hallo McMlxx, wenn dem nachweisbar so ist, dann nimm es meinetwegen raus (bitte mit Nachweis). Ich habe mich am hiesigen Artikel Scriptsprache orientiert. Gehört denn die für die MS-DOS-Batchdateien benutzte Sprache nicht auch zu den Scriptsprachen? Letztendlich ist im weiteren Sinn ja ein Script auch ein Programm (gespeicherte Abfolge von Funktionsaufrufen), und die Jobs im Großrechnerbereich wie auch die DOS-Batchdateien (womit ich früher gern gearbeitet habe), sehe ich als solche an. Ich bin alter EDV-Praktiker und mit den möglichen Feinheiten von Begriffsbestimmungen der Informatik nicht unbedingt vertraut. Wenn du (oder jemand anderes) die Frage "wissenschaftlich präzise" beantworten kann, nur zu! Ich bin nicht so eitel, dass ich nicht gern "noch" schlauer werden möchte. Herzliche Grüße! --Remirus 14:10, 6. Okt. 2011 (CEST)

1. Diese Diskussion ist müßig, da es keine exakte Definition von „Skriptsprache“ gibt. Es gibt lediglich pragmatische Einordnungen, die letztlich willkürlich einbeziehen oder nach oben oder unten ausgrenzen.
2. Der Begriff und das Verständnis, was darunter fallen sollte, hat sich in den Jahrzehnten der sich laufend wandelnden Informationstechnik auch immer mal wieder geändert. Das gilt genauso für die Begriffe „Textverarbeitung“, „CAD“, „DTP“, „Künstliche Intelligenz“ und viele andere.
3. Eine Skriptsprache hat wohl eine ähnliche Bedeutung wie die genauso schwammig umrissene „Makrosprache“. Unter einer Skriptsprache versteht man allgemein erst mal eine Abfolge von Kommandos an ein Softwareprodukt, die aufgezeichnet werden können und später wiederholt als ein Kommandostapel (Skript) ausgeführt werden können. Das wird dann oft mit Parametern $1, $2 oder %1% und %2% oder $EINGABEDATEI flexibler gemacht, und es gibt über die nackte Abfolge von Kommandozeilen hinaus Steueranweisungen FOR oder WHILE und IF. Das gesteuerte Softwareprodukt kann ein Grafikprogramm sein, oder ein Betriebssystem, oder Werkzeugmaschinen werden bedient.
4. Manche ursprünglich nur interpretierbare Sprache als stereotype Abfolge von Kommandozeilen ist in der weiteren Entwicklung auch kompilierbar geworden, etwa VBA oder Python. Die diversen Shell-Skripte sind auch nichts anderes als „Steueranweisungen an das Betriebssystem“.
5. Als Abfolge von Kommandos fällt JCL zweifelsfrei unter „Skriptsprache“. Trotz des biblischen Alters (1964) sind offenbar auch Elemente „höherer“ Programmiersprachen wie PROC...PEND und IF-THEN-ELSE vorhanden, an Variablen mindestens die erwähnten Return-Codes.

VG --PerfektesChaos 18:51, 6. Okt. 2011 (CEST)

Hallo zusammen,
wenn man Skriptsprache als eine Folge von Befehlen an ein übergeordnetes System sieht, dann ist die JCL eine Skriptsprache.

JCL ist aber keine Programmiersprache, denn es fehlen wesentliche Bestandteile wie Modularisierung und Schleifenbildung. Ein Rückbezug innerhalb eines Jobs ist möglich (IF-THEN-ELSE), aber kein Rücksprung im Sinne von: mach-das-nochmal. Ein Job kann auch keinen anderen Job aufrufen.

Da ich als Wiki-Neuling nicht sofort den Artikel ändern wollte, hab ich es erst mal über die Diskussionsseite angesprochen. Ich denke, wenn man den Artikel in „und ist eine Art Skriptsprache“ ändert, ist der Sache am meisten gedient.

Grüße --McMlxx 07:17, 7. Okt. 2011 (CEST)

• Wie oben schon gesagt: Es gibt keinerlei Definition, was eine Skriptsprache ist; somit auch nicht, was „wesentliche Bestandteile“ dafür sein müssen.
  • Modularisierung und Schleifenbildung sind nett; Schleifen wären in der Tat schön gewesen. Modularisierung ließe sich offenbar über PROC...PEND bilden.
  • Das Ganze ist ein Kind der 1960er Jahre und der damaligen Möglichkeiten. Im Sinn des 20. Jahrhunderts ist es zweifelsfrei eine Skriptsprache; wenn jemand aus Sicht des 21. Jahrhunderts für sich persönlich postuliert, dass nur noch bei Ausstattung mit objektorientierten Sprachelementen das Prädikat „Skriptsprache“ vergeben wird, bleibt das jedem unbenommen.
  • Der Artikel Skriptsprache geht mit der Problematik vorbildlich um; wo präzise Definitionen nicht existieren, kann die WP solche nicht vortäuschen und formuliert: „verzichten oft auf“, „Häufig vorhandene Merkmale“, usw. Historisch richtig heißt es: „Wurden Skriptsprachen anfangs nur für kleinere Automatisierungen verwendet“ … und die 1960er sind gerade diese Anfangsphase. Die Leute mit den Lochkarten waren froh, dass sie nicht für jeden ähnlichen Lauf denselben Stapel an Lochkarten zusammensortieren mussten, sondern eine vorbereitete und sich selbsttätig „intelligent“ an wechselnde Rahmenbedingungen anpassende Prozedur mit nur einer Lochkarte abgerufen werden konnte.
• Da das Themenfeld von „Skriptsprache“ bis „interpretierte Programmiersprache“ bis „richtige Programmiersprache“ völlig schwammig ist, und control language der in den 1960er Jahren gebräuchliche Begriff für genau das ist, was bei Unix bald darauf script language hieß, gewinnt der Artikel nichts durch das vorgeschlagene „eine Art“. Eher schon durch einen Zeitbezug; jeder Großrechner der damaligen Zeit musste notgedrungen eine derartige Sprache anbieten.
• Wie ich eingangs meiner ersten Bemerkung schon formulierte: Diese Diskussion ist müßig.
• Gleichwohl ist es gut und empfehlenswert, dass die Frage zunächst in der Diskussion thematisiert wurde, statt sofort den Artikel inhaltlich zu ändern.

Beste Grüße --PerfektesChaos 09:24, 7. Okt. 2011 (CEST)

Hallo zusammen, mein Fazit aus dieser kleinen, aber interessanten Diskussion ist nach wie vor, dass meine Aussage eher richtig als falsch war. Ich schlage daher vor, dass sie bis zum eindeutigen Beweis des Gegenteils (z. B. Beleg aus einschlägiger Fachliteratur) stehen bleibt. Herzliche Grüße! --Remirus 17:36, 7. Okt. 2011 (CEST)

Hallo,
aus G. D. Brown zOS/JCL Job Control Language im Betriebssystem z/OS MVS, 4. Auflage, Kapitel 1.2, Seite 3:
"1.2 Die Rolle der JCL
Mit Hilfe der JCL werden nicht etwa Computer-Programme geschrieben. Vielmehr besteht die JCL aus Statements (Steuerungsanweisungen), die dem Betriebssystem eine Arbeit - einen Job - bekanntmachen. Abrechnungsinformationen beteitstellen, die Arbeitsweise des Betriebssystems steuern, Hardware-Einheiten anfordern und schließlich den Job zur Ausführung bringen. Die JCL hat dem Betriebssytem jedes Deteil mitzuteilen, das es bezüglich der Durchführung der Ein- und Ausgabedaten wissen muß. Oberhalb der JCL gibt es typischerweise ein Job Entry Subsystem (JES) mit einer dazugehörenden Sprache.... IBM stellt im z/OS zwei Job Entry Subsyteme zur Verfügung: JES2 ... und JES3... JCL und JES gehören zusammen, und so werden sie in diesem Buch beschrieben.
Daraus folgt für mich:
- die JCL gibt es nur im Mainframe-Bereich (z/OS)
- Skripte sind eher im Server- bzw. PC-Bereich zu finden. (z. B. Shell-Skript im Unix-Bereich ode BAT.Dateien beim PC)
- eine Skriptsprache aus dem z/OS-Umfeld ist REXX
- JCL und Skripte sind vielleicht vergleichbar aber nicht das gleiche.
mit freundlichen Grüßen --McMlxx 11:02, 13. Okt. 2011 (CEST)

Hallo McMlxx, du hast geschrieben: Skripte sind eher im Server- bzw. PC-Bereich zu finden. und JCL und Skripte sind vielleicht vergleichbar aber nicht das gleiche. Aus deinem Zitat lese ich diese Aussagen aber nicht heraus. Damit bleibt für mich die Frage nach wie vor offen. Herzliche Grüße! --Remirus 09:31, 14. Okt. 2011 (CEST)

1. Diese Diskussion ist müßig.
   • Da es keine exakte oder gar allgemeingültige Definition von „Skriptsprache“ gibt, kannst du (McMlxx) für dich persönlich einsortieren was immer du magst.
   • Die eingangs dieses Thread von dir gemachte Aussage „Skriptsprachen werden als Programmiersprachen angesehen“ im davon abgrenzendem Kontext „JCL ist eine Folge von Informationen und Steueranweisungen an das Betriebssystem“ nennt man in dieser Welt TF. In dieser Exklusivität würde sie nur die nicht-anwendungsbezogenen Sprachen der Generation des 21. Jahrhunderts nahelegen; wobei die Definitionsfrage offen bleibt, was genau in diesem Sinn eine „Programmiersprache“ sein möge und warum die Sprachen des 20. Jahrhunderts nicht darunter fallen sollen. Notwendig ist lediglich „formale Sprache“, JCL erfüllt die unter Imperative Programmierung genannten Bedingungen. Jede Skriptsprache ist zunächst Interpretersprache, JCL aber auch.
2. In den 1960ern gab es nur Control Languages und bekanntermaßen nur Mainframes.
   • Die 1970er brachten den Ausdruck scripting language in Unix und meinten damit das Gleiche: Auf Benutzerebene vordefinierbare Abfolge von Betriebssystemkommandos.
   • In den 1980ern brachte MS-DOS mit den .BAT das Gleiche zu den nun verfügbaren PC. (.BAT: batch, Stapelverarbeitungsdatei, "batch job" – klingelt’s?)
   • War Unix logischerweise zunächst für Mainframes gedacht, ist es bekanntlich als Linux auch auf PC verfügbar. Wenn jemand mag, könnte er JCL auch auf PC emulieren.
3. Die wiederholbare Abfolge von Betriebssystemkommandos ist bereits ein Skript („Stapelverarbeitung“).
   • Wenn dies nur ein konstanter Stapel an Befehlen ist, hatte man das auch "Makro" genannt. (Ebenfalls kein präziser Begriff.) Auch die stereotype Ausführung von einem Dutzend Einzelbefehle ist bereits eine Arbeitserleichterung – dies durch ein einzelnes und ausgetestetes Kommando zu ersetzen.
   • Sobald ein zusätzliches Syntaxelement hinzukommt, das selbst kein Betriebssystemkommando ist, wird daraus eine eigenständige „Sprache“. Das können sein:
     1. Parameter, denen wechselnde Werte zugewiesen werden können und die mit ihrem aktuellen Inhalt zu verwenden sind.
     2. Steuerungselemente innerhalb des Skripts, wie IF oder FOR, WHILE usw., auch GOTO.
   • Die zusätzlichen Syntaxelemente werden bei der Ausführung durch Interpreter herausgefiltert und resultieren in einer Abfolge ausführbarer Betriebssystemkommandos, die nach der Interpretation auch keine Parameter mehr enthalten. Die Abfolge richtet sich ggf. „intelligent“ nach dem jeweiligen Systemzustand und Aufrufparametern. Die notwendige Zwischenschaltung des Interpreters macht daraus eine „interpretierbare Programmiersprache“.
4. Es ist eine Trivialaussage, dass in den 1960ern eine Sprache weniger mächtig war als 2000.
   • Die Komplexität der Software, die Leistungsfähigkeit der Systemsoftware und die Anforderungen an Bediensicherheit wie Benutzerkomfort stiegen mit den Jahrzehnten genau wie die Möglichkeiten der Hardware.
   • Neben JCL gab es auch für die Anlagen von Control Data auch CCL (hier ein Inhaltsverzeichnis – viel mehr gibt es nicht im Web) – in dieser Sprache hatte ich mal einige 1000 Zeilen geschrieben; aushilfsweise auch mal einige Zeilen in JCL.
   • Vor dem von dir genannten REXX gab es EXEC 2 (auch in EXEC 2 schrieb ich schon, eine eher magere Angelegenheit). Letzere beschreibt der zitierte Artikel zutreffend als „nicht sehr mächtig“. Das ist halt so, dass die Sprachen mit den Jahrzehnten immer mächtiger wurden, also immer mehr eigene Syntaxelemente enthalten – das sind aber nur graduelle Unterschiede, keine prinzipiellen.
5. Die „Skriptsprachen“ lassen sich in drei Bereiche gliedern:
   1. Betriebssystemkommandos, die historisch älteste Aufgabe
   2. Anwendungsprogramme, beispielsweise Grafik oder Textverarbeitung (ich fand bei der Suche nach CCL zufällig auch cybercontrol)
   3. Loslösung von konkreten Problemen, etwa Python, Perl, VBA in der modernen Welt.

HGZH --PerfektesChaos 01:09, 16. Okt. 2011 (CEST)

Jobsteuersprache ≠ Programmiersprache

Bezüglich der "Meinung" des Projektleiters: Ungeachtet dessen, ob dieser JCL als beste, mittelmäßige oder schlechteste Programmiersprache bezeichnet, ist eine derartige Einordnung per se unzutreffend, da JCL nun mal keine Programmiersprache ist und somit schon die Prämisse falsch ist. Gruß --Invisigoth67 (Disk.) 16:37, 19. Apr. 2024 (CEST)

Bez. "Quelle": Da JCL keine Programmiersprache ist, liegt die Bringschuld von reputablen Belegen, JCL sei eine Programmiersprache, bei Dir, wenn Du so etwas einfügen möchtest, auch wenn der OS/360-Projektleiter das noch oft fälschlicherweise behauptet. Natürlich hat "keiner der Entwickler realisiert, dass JCL tatsächlich eine Programmiersprache sei", da es nun mal keine ist. JCL ist ein Set an Steueranweisungen zur Durchführung von Jobs, die ihrerseits die Programme aufrufen, die mittels tatsächlicher Programmiersprachen (damals Assembler, PL/I und COBOL) geschrieben wurden und deren Aufgabe die eigentliche Datenverarbeitung ist. Daher bezeichnet IBM JCL freilich auch nicht als Programmiersprache. --Invisigoth67 (Disk.) 16:23, 26. Apr. 2024 (CEST)

Frederick P. Brooks ist als Quelle so reputabel, wie er nur sein kann: Hauptverantwortlicher für das System/360 (Hardware und Software), Turing-Award-Träger, Autor mehrerer Bücher über Computer- und Software- Architektur (u.a. The Design of Design), Professor für Informatik. Wenn es irgendjemand beurteilen kann, dann er.--Trex4321 (Diskussion) 20:30, 27. Apr. 2024 (CEST)

Durch Schreien wird es auch nicht zutreffender. Am besten kann es selbstverständlich IBM beurteilen, die JCL entwickelt haben und seit Jahrzehnten warten/weiterentwickeln und als Bestandteil von auf OS/360 basierenden Betriebssystemen noch heute vertreiben. Und IBM bezeichnet JCL aus nachvollziehbaren Gründen nicht als Programmiersprache, da es nun mal keine ist oder als solche konzipiert war (weshalb auch der Satz " ... keiner der Entwickler realisierte, dass JCL tatsächlich eine Programmiersprache sei ..." absurd ist, weil er von falschen Voraussetzungen ausgeht). Wie gesagt: Die Programmiersprachen auf IBM-Mainframes waren damals Assembler, PL/I und COBOL, aber eben nicht JCL. --Invisigoth67 (Disk.) 09:13, 30. Apr. 2024 (CEST)

Relevanz einer eher scherzhaft formulierten Einzelmeinung eines Ex-Mitarbeiters?

Brooks' nahezu hyperlative Formulierung, dass er "... überzeugt sei, dass JCL die schlechteste Programmiersprache, die jemals irgendwann von irgendjemandem entwickelt wurde, ist ...", inklusive falscher Einordnung von JCL als Programmiersprache, ist bestenfalls sachlich falsch und effekthascherisch, aber jedenfalls nicht erst zu nehmen. Dass er als damaliger Projektleiter des aus unzähligen Einzelkomponenten bestehenden OS/360-Projekts, der somit für alles Mögliche zuständig war, sich fast 50 Jahre nach seinem vorzeitigen Ausscheiden aus dem damals noch laufenden OS/360-Projekt in einem Buch so nebenbei über JCL derartig äußert, mag befremdlich sein, aber da es (laut Buch-Untertitel) bloß eine Sammlung von Essays ist, hat man als Autor freilich einige künstlerische Freiheiten.

Aus all diesen Gründen ist diese (vermutlich) nicht sachlich ernst gemeinte, flapsig-scherzhafte Anmerkung in einem anekdotenhaften Essay für diesen Artikel irrelevant, weshalb die Einfügung dieses Absatzes abzulehnen ist. --Invisigoth67 (Disk.) 09:13, 30. Apr. 2024 (CEST)

Die Behauptung, dies sei eine scherzhaft formulierte Einzelmeiung und nicht sachlich ernst gemein, ist falsch und auch nicht durch irgendeine Quelle gedeckt.

Vielmehr ist das ist eine Kernaussage des 14. Kapitel ("How Expert Designers go Wrong") des Buches "The Design of Design" von Professor Brooks. JCL wird dort als Musterbeispiel für das Scheitern von Designprozessen herangezogen, und er untersucht im Detail, wie es dazu kommen konnte. Meines Wissens ist dies die einzige Quelle, die sich mit dem Design (und den Fehlern) von JCL überhaupt beschäftigt, und er tut das systematisch und gründlich. Das hat mit "angekdotenhaftem Essay" rein gar nichts zu tun. Ich würde in diesem Fall tatsächlich empfehlen, mal in die Quelle reinzuschauen, statt sich in unbegründeten und falschen Vermutungen zu ergehen.

Anderes Zitat: Der Abschnitt "So what's wrong with JCL?" beginnt mit "The biggest flaw of all was that JCL is a programming language, but it was not perceived as such by its designers" (S. 170). Danach geht er dann im Detail darauf ein, was die Fehler sind, und beschreibt auch, warum erfahrene Designer sie begehen konnten.

Natürlich ist die Bemerkung provokant, das ist auch von anderen Aussagen von Brooks bekannt, vergleiche Brooks's law aus Vom Mythos des Mann-Monats.

Und schließlich: Wenn du eine andere Quelle von vergleichbarer Provenienz hast, die das Gegenteil behauptet (dass JCL keine Programmiersprache sei), dann zitier sie und wir diskutieren das weiter. --Trex4321 (Diskussion) 21:23, 30. Apr. 2024 (CEST)

Da Du diese Zitate in den Artikel einfügen möchtest, liegt die Beweislast bei Dir, ich muss also nicht beweisen, dass JCL keine Programmiersprache ist (was sich schon aus dem Studium dieses Artikels ergibt), sondern Du musst beweisen, dass sie eine ist. Wie gesagt, auch der Hersteller IBM bezeichnet sie nicht so, siehe z. B. hier. Mit JCL werden Programme aufgerufen, aber nicht geschrieben. Es reicht schon, sich nur oberflächlich mit JCL zu befassen, um zu erkennen, dass es nur ein Set an Steueranweisungen für Batch-Jobs ist, aber keine Programmiersprache.

Aber wie gesagt, es liegt ja nicht bloß an der falschen technischen Kategorisierung von JCL, sondern auch daran, dass es nun mal eine Einzelmeinung aus einem Essay ist und sie schon alleine aufgrund der völlig überzogenen Formulierung per se absurd ist und sich als seriöse Kritik disqualifiziert (und somit vermutlich ohnehin nur als scherzhafte Übertreibung gemeint war, um auf die Schwächen von tatsächlichen Programmiersprachen hinzuweisen).

Daher ist das in Summe im enzyklopädischen Kontext nicht zu gebrauchen. --Invisigoth67 (Disk.) 16:21, 1. Mai 2024 (CEST)

Ich habe bewiesen, dass sie eine ist, mit mehreren Zitaten von derAutorität auf dem Gebiet, Brooks.

Und es ist tatsächlich nicht nur ein Set an Steueranweisungen, siehe COND und PROC. COND ist eine verstümmelte Verzweigung, PROC ist ein Makro. (Mittlerweile ist die JCL sogar schon mit IF erweitert worden, siehe [1]https://www.ibm.com/docs/en/rbd/9.5.1.2?topic=zos-if-statement . Ich habe JCL jahrelang benutzt und durchaus auch kompliziertere Dinge damit getan, auch wenn es selten wirklich Spaß gemacht hat.

Und das, was du abschätzig als Einzelmeinung abqualifizierst, ist das wohl begründete Urteil des Projektverantwortlichen, der sich im Übrigen mit dieser drastischen Formulierung auch selber eines des Versagens bezichtigt.

Und es ging speziell um die massiven Schwächen von JCL und nicht um andere Programmiersprachen. Deine Vermutungen liegen aus irgendeinem Grund anscheinend mit einer gewissen Systematik daneben. --Trex4321 (Diskussion) 21:11, 1. Mai 2024 (CEST)

An den von mir vorgebrachten Argumenten ändert das allerdings nichts (und die IF-Karte hat im Vergleich zu Programmiersprachen einen minimalistischen Umfang und dient bloß dem Job-Scheduling bzw. der Inklusion/Exklusion von Datenbeständen).

Fakt bleibt, dass JCL keine Programmiersprache ist und man mit damit keine Programme schreiben kann (was Sinn und Zweck von Programmiersprachen ist). Fakt bleibt, dass der Hersteller IBM und auch sonstige Quellen JCL nicht als Programmiersprache bezeichnen, sondern nur Fred Brooks. Und die scherzhaft-übertriebene Formulierung "... schlechteste Programmiersprache, die jemals irgendwann von irgendjemandem entwickelt wurde ..." kann nicht als sachlich seriöse und technisch korrekte Kritik ernst genommen werden. --Invisigoth67 (Disk.) 08:25, 3. Mai 2024 (CEST)

Dieses Video seines Vortrags anlässlich einer Veranstaltung zu 40 Jahre System/360 beweist übrigens, dass die Anmerkung von Brooks scherzhaft gemeint war, das Publikum bricht hier in Gelächter aus und auch Brooks selbst lacht, während er das ausführt. Sogar IBM selbst verwenden den Scherz in ihren Workshop-Folien, um den Unterschied zwischen JCL und tatsächlichen Programmiersprachen zu verdeutlichen bzw. was JCL eigentilch ist ("JCL is best thought of as a single mechanism to execute all programming languages"). Damit sollte nun endgültig klar sein, dass dieses humorige Zitat weder sachlich zutreffend noch ernst gemeint ist und somit irrelevant ist. Weitere Meinungen? --Invisigoth67 (Disk.) 09:14, 3. Mai 2024 (CEST)

Also haben die Leute über eine provokante Formulierung gelacht. So what? --Trex4321 (Diskussion) 14:12, 3. Mai 2024 (CEST)

Die Aufgabe von JCL ist die gleiche wie der Unix-Shell - größtenteils das Starten von Programmen, nur halt für das batch-orientierte MVS (wenn ich MVS mal als Abkürzung von OS/360 bis zOS nehme), mit dem Unterschied, dass es sich um eine Sprache für den Batchbetrieb handelt. Wenn man unter UNIX ein Batch-System wie slurm [2] verwendet, wird die Ähnlichkeit noch größer - die benötigten Ressourcen werden bei JCL auf der Jobkarte und bei Slurm als Kommentar in einem Shellscript angegeben.

Nun sind Unix-Shells zweifellos Programmiersprachen. Ist JCL, die prinzipiell die gleiche Funktion erfüllt (Programmstart) daher auch eine Programmiersprache? Brooks argumentiert dafür (und ich kann auch weniger scharf formulierte Sätze aus dem gleichen Kapitel einfügen, oder gleich die ganze Kritik, die auch noch andere Punkte umfasst). Hauptoroblem sind die sehr schwachen Kontrollstrukuren, die ausschließlich das Skippen von Steps umfassen (ich habe den COND-Parameter mal als Beispiel eingefügt, wenn sich beim Lesen dieses Abschnittes Knoten im Hirn bilden, ist das nicht ungewöhnlich).

Warum Dinge, die bei der Entwicklung schiefgelaufen sind, nicht in "Entwicklung" gehören, erschließt sich mir allerdings nicht.

Und in Gebrauch ist sie weiterhin, auf zOS, dem MVS-Nachfolger. Natürlich ausschließlich zum Starten von Batch-Jobs. Da wurde dann auch das IF-Statement eingefügt, um die Kontrollstrukturen wenigstens ein bisschen zu verbessern. --Trex4321 (Diskussion) 16:10, 3. Mai 2024 (CEST)

Es geht doch vor allem darum, dass diese scherzhafte Anmerkung (dass das nicht ernst gemeint war, sollte mittlerweile klar sein) keinerlei enzyklopädische Relevanz hat. Zu kritisieren, dass JCL keineswegs den Umfang hat, dass man damit Programme schreiben könnte, ist sinnlos, da das im Vergleich zu den Programmiersprachen (Assembler etc.) ja gar nicht geplant war, denn JCL wurde vor 60 Jahren lediglich zu dem Zweck gebastelt, Batch-Jobs durchzuführen. --Invisigoth67 (Disk.) 17:24, 3. Mai 2024 (CEST)

Entgegen deiner Behauptung ist es keineswegs klar, dass diese Bemerkung scherzhaft gemeint ist.

Aber meinetwegen können wir sie auch durch eine Übersetzung von "The biggest flaw of all was that JCL is indeed a programming language, but it was not perceived as such by its designers" ersetzen, wenn du auf falsch vermuteten Humor allergisch reagierst. --Trex4321 (Diskussion) 19:17, 3. Mai 2024 (CEST)

Mir persönlich Allergien zu unterstellen ist nicht hilfreich, und der Humor ist nicht falsch vermutet, Brooks hat ja selbst dabei gelacht. Es bleibt eine scherzhaft übertriebene Einzelmeinung von Brooks, da bräuchte es schon weitere, diesmal vor allem sachlich-ernsthafte Belege. --Invisigoth67 (Disk.) 19:56, 3. Mai 2024 (CEST)

Also einverstanden mit der Übersetzung? --Trex4321 (Diskussion) 20:14, 3. Mai 2024 (CEST)

Nein, es bleibt ja eine spekulative Einzelmeinung. --Invisigoth67 (Disk.) 20:34, 3. Mai 2024 (CEST)

Deine Argumentation, wenn Leute drüber lachen, dann sei es nicht relevant, kann ich nicht nachvollziehen.

Und es bleibt dabei, das Brooks *die* Autorität ist und man seine Aussagen genauso wenig als Einzelmeinung abtun sollte wie die Aussage von Kernighan über UNIX, dass die UNIX-Shells Programmiersprachen sind, siehe Shellskript. --Trex4321 (Diskussion) 12:47, 4. Mai 2024 (CEST)

Wie gesagt: Er selbst lacht, als er das sagt, das Publikum lacht auch. Natürlich ist Brooks ein renommierter Informatiker, deshalb ist es auch beruhigend, dass seine Anmerkung nicht ernst gemeint ist, denn etwas, egal ob Programmiersprache oder nicht, als "schlechteste Programmiersprache, die jemals irgendwann von irgendjemandem zu irgendeinen Zweck entwickelt wurde" zu bezeichnen, ist entweder blanker Unsinn oder ein augenzwinkernder Scherz (anhand dessen dann zu seriösen Aussagen übergeleitet werden kann). So eine scherzhaft-übertreibene Anmerkung hat null enzyklopädische Relevanz. --Invisigoth67 (Disk.) 14:39, 4. Mai 2024 (CEST)

Auch wahre Aussagen können für Erheiterung sorgen, vor allem wenn alle Beteiligten sie mehr oder weniger reumütig eingesehen haben und über ihren eigenen Erkenntnisprozess lachen. Insofern beweist sowas gar nichts. --Trex4321 (Diskussion) 18:57, 5. Mai 2024 (CEST)

Da Du das ja (hoffentlich) nicht ernst meinst, ist dann wohl alles geklärt. --Invisigoth67 (Disk.) 14:38, 6. Mai 2024 (CEST)

Wieso sollte das nicht ernst gemein sein?

Aber von mir aus ist alles geklärt, wenn das Zitat drinbleibt. --Trex4321 (Diskussion) 20:29, 7. Mai 2024 (CEST)

Dass das Zitat um des Zitates willen in den Artikel soll, ist allerdings auch kein Agrument. --Invisigoth67 (Disk.) 10:30, 8. Mai 2024 (CEST)

Fazit aus der bisherigen Diskussion:

• Das Zitat von Brooks ist aufgrund der massiv übertriebenen Formulierung per so unsachlich, irreführend und falsch und daher fachlich/enzyklopädisch nicht als seriöse Beurteilung akzeptabel
• Dass es sich um eine nicht ernst gemeinte, scherzhafte Übertreibung handelt, ist mittlerweile erwiesen und belegt
• Die Äußerung einer einzelnen Person, die noch dazu als Ex-Mitarbeiter involviert war, ist nicht neutral und eben nur eine Einzelmeinung

Aus all diesen Gründen ist die konsensfreie Einfügung von Brooks' Anmerkungen abzulehnen. Wenn die Unterschiede zwischen JCL und Programmiersprachen bzw. anderen "Sprachen" dargestellt werden wollen, dann bitte nur enzyklopädisch neutral und anhand von unabhängigen Quellen. --Invisigoth67 (Disk.) 10:30, 8. Mai 2024 (CEST)

Dritte Meinungen

• Ein paar Gedanken von jemandem, der von der Materie praktisch keine Ahnung hat, vielleicht gerade deshalb hilfreich... a) es scheint eine Meinungsverschiedenheit zu geben, was für eine Art von Sprache hier vorliegt. Dazu fällt mir auf, dass der Begriff 'Steuersprache' in der Einleitung nicht verlinkt ist, warum? Ob Steuer- oder Programmiersprache sollte unabhängig von dem wie auch immer gemeinten Statement ihres Entwicklers ausreichend belegt sein, das scheint aktuell nicht der Fall zu sein. b) Da dann das Zitat nicht mehr als (alleiniger) Beleg herhalten muss, kann es an einen geeigneteren Ort verschoben werden, etwa "Rückblick/Rezeption/Trivia". Es gehört sachlich nicht in einen Abschnitt "Entwicklung". c) In dem Zusammenhang fällt mir auf, dass nicht so richtig klar wird, ob die Sprache heute noch in Gebrauch ist? (als angeblich schlechteste...?), vielleicht auch noch mehr zu Anwendungsgebieten, Bedeutung? Grüße, --Coyote III (Diskussion) 11:07, 3. Mai 2024 (CEST)

Was braucht denn eine Programmiersprache?

Vielleicht mal einen Schritt zurück - was ist denn für eine Programmiersprache nötig?

JCL hat Verzweigungen über COND und mittlerweile auch IF/THEN/ELSE/ENDIF, es kann auch Iterationen über SYSOUT=(A,INTRDR), (auch wenn das von hinten durch die Brust ins Auge ist), es hat eine Art von Makro-Facility (PROC), es hat Variablen (SET). (nicht signierter Beitrag von Trex4321 (Diskussion | Beiträge) 12:43, 4. Mai 2024 (CEST))

Ist letztlich zweitrangig, da es weniger darum geht, was eine Programmiersprache ist oder nicht, sondern um die scherzhafte Anmerkung, da JCL nun mal sicher nicht das "schlechteste (was auch immer), das jemals irgendwann von irgendjemandem zu irgendeinen Zweck entwickelt wurde" ist. Aber um dennoch zu antworten: selbst ZX-81-BASIC hatte eine GOTO-Anweisung, mit der man "wieder nach oben" springen konnte. Das und vieles mehr hat JCL nicht. Mit JCL kann man keine Daten verarbeiten, sondern nur den Aufruf von Programmen steuern, die tatsächlich Daten verarbeiten. --Invisigoth67 (Disk.) 14:39, 4. Mai 2024 (CEST)

Programmiersprachen sind nicht nur dazu da, Daten zu verarbeiten, oder ist das auch die Hauptaufgabe der UNIX-Shells?

Hmm, da waren wir schonmal: Dass der Hauptfehler am JCL-Design war, dass die Designer nicht kapiert haben, dass wie eigentlich eine Programmiersprache entwarfen, ist für dich also zweitrangig? D.h. das würdest du zugestehen?

Aber noch eine andere Frage: Da du mit so viel Engagement an der Diskussion über JCL bist, hast du eigentlich professionell mit zOS und JCL zu tun? --Trex4321 (Diskussion) 19:00, 5. Mai 2024 (CEST)

Mit Deine Fragen liegst Du völlig falsch. Im übrigen bezeichnet Brooks selbst JCL als "eine Jobsteuersprache für die sechs echten Programmiersprachen", was ja seinen Scherz noch ein wenig scherzhafter (oder absurder) macht. Aber was ist eigentlich Deine Motivation, dass Deine einzige Aktivität bzw. Dein einziges Interesse in Wikipedia in den letzten Wochen ausschließlich der Versuch, dieses komische Zitat in dem Artikel unterzubringen zu wollen, ist? --Invisigoth67 (Disk.) 14:38, 6. Mai 2024 (CEST)

Du meinst, mit den Fragen liege ich falsch. Dann interpetiere ich das mal so, dass die Antworten für dich nicht hilfreich wären. Wenn du keine Lust dazu hast, sie zu beantworten, dann kann ich das auch selber tun.

Die Hauptaufgabe von UNIX-Shells ist zweifelsfrei, Prozesse zu starten, entsprechend JC (nur dass das da ein bisschen anders heißt, ein Job entspräche einer Session und ein Job Step einem Prozess). Sie verfügen über Kontrollstrukturen und Stringvariablen, genauso wie JCL. Allerdings sind die Kontrollstrukuren von JCL im Gegensatz zu UNIX-Shells so sehr eingeschränkt, das die Bezeichnung "schlechteste Programiersprache" durchaus zutrifft - und wie gesagt, über INTRDR kann man auch Iterationen machen.

Deine Vorstellung, Programmiersprachen dienten nur dem Verarbeiten von Daten, ist hingegen völlig daneben, wie man gerade an den UNIX-Shells sieht.

Ob du für IBM arbeitest: Eine Ja- oder Nein-Frage kann nicht völlig daneben liegen, die kann man mit Ja oder Nein beantworten. Da du ihr ausweichst, könnte man so allmählich tatsächlich vermuten, dass du mit JCL arbeitest, vielleicht sogar für IBM. Aber wie gesagt, das ist eine lediglich eine leise Vermutung, du kannst mir natürlich widersprechen, sollte sie falsch sein und falls du Wert darauf legst, diese Vermutung zu zerstreuen. Andererseits ist das vielleicht auch nicht so, weil du die Sprache doch nicht so gut zu kennen scheinst.

Du scheint dich ja vor allem an dem vermuteten Humor der Aussage zu stören, aber mein Vorschlag, andere Zitate aus dem gleichen Abschnitt einzufügen, die den Hauptpunkt der Designfehler von JCL betreffen, passte dir ja auch nicht (vermutlich wegen deiner nicht haltbaren Meinung zu Programmiersprachen).

Und warum ich das im Augenblick verfolge: Ich finde es wichtig für das Verständnis von JCL, dass man versteht, wieso diese Sprache so extrem merkwürdig ist, wie sie nun mal ist (vergleiche den Jargon File entry dazu) [3] Als jemand, der selber JCL-Decks geschrieben hat, um mit JES2 Job-Ping-Poing zwischen verschiedenen Mainframes zu spielen (das Gerücht, dass es nur ein einziges Deck gäbe, was immer wieder kopiert und geändert wurde, stimmt nicht) habe ich durchaus noch ein Interesse an der Sache (ich habe ja auch den COND-Parameter in den Artikel eingeführt). Und bezüglich Zeit - wenn die Sache bereinigt ist, dann habe ich auch wieder für andere Sachen Zeit, ich wollte mir mal wieder ein paar alte Computersysteme vornehmen.

Aber vielleicht kann man des Zitates einen Abschnitt "Rezeption" oder "Kritik" einführen, wo man die einzelnen Sachen so aufführt, der wäre dann vermutlich ausführlicher. --Trex4321 (Diskussion) 18:32, 6. Mai 2024 (CEST)

Auf das Niveau, jemandem ad personam falsche und haltlose Behauptungen, Vermutungen und Unterstellungen zu privaten Dingen wie Arbeitgeber und technischem Arbeitsumfeld unterschieben, werde ich mich nicht begeben. Aber dass ich die als Vermutung formulierten Fragen als unzutreffend verneint habe, war ja wohl erkennbar, auch wenn das niemanden etwas angeht noch es für diese WP-interne Diskussion relevant ist. Und nein, Du wird keine an mich gerichtete Fragen an meiner statt beantworten.

Man kann ein Produkt nicht ernsthaft für etwas kritisieren, wofür es gar nicht gedacht ist, solange es seine bescheidene Aufgabe erfüllt. Ich kritisiere mein Smartphone ja auch nicht dafür, dess es keinen Subwoover und keinen 60-fachen optischen Zoom hat, weil es dafür nicht gedacht ist, sondern nur für einfache Audiowiedergabe und digitalen Zoom. Der sehr überschaubare Funktionsumfang von JCL ist "works as designed", da man damit nichts anderes macht als Jobs durchzuführen. Und das wird im Artikel ja auch sachlich und neutral beschrieben. --Invisigoth67 (Disk.) 10:30, 8. Mai 2024 (CEST)

Nur noch kurz: Meine Frage bezüglich IBM bezog sich auf einen möglichen Interessenkonflikt. --Trex4321 (Diskussion) 20:32, 8. Mai 2024 (CEST)