Der entscheidende Punkt gleich zu Beginn: JCL ist keine Programmiersprache im klassischen Sinn. Man rechnet mit ihr nicht, man formuliert keine Geschäftslogik, keine Schleifen über Datensätze und keine Berechnungen. Stattdessen beschreibt JCL das Umfeld, in dem andere Programme laufen – geschrieben etwa in COBOL, PL/I oder Assembler. JCL sagt dem System: Führe dieses Programm aus, gib ihm jene Eingabedateien, schreibe die Ausgabe dorthin, reserviere so viel Arbeitsspeicher und mach mit dem nächsten Schritt nur weiter, wenn der vorherige erfolgreich war. In diesem Sinn ist JCL eine Regie- und Steuersprache, die Programme zu einem geordneten Ablauf zusammenfügt.
Drei Eigenschaften prägen JCL:
JCL trägt ihre Herkunft aus der Ära der Lochkarten bis heute sichtbar in sich. Viele ihrer formalen Eigenheiten – die feste Spaltenorientierung, die Beschränkung auf Großbuchstaben, die kompakte, kryptisch wirkende Schreibweise – stammen aus einer Zeit, in der jede Zeile physisch auf eine Karte gestanzt wurde. Diese Prägung erklärt, warum JCL für heutige Augen ungewohnt und spröde aussieht: Sie wurde nicht für Lesbarkeit, sondern für maschinelle Verarbeitbarkeit unter sehr engen Rahmenbedingungen entworfen.
Dass eine solche Sprache über ein halbes Jahrhundert überdauert hat, ist kein Zufall, sondern Ausdruck der Stabilität der Mainframe-Welt. Großrechner verarbeiten bis heute einen erheblichen Teil der geschäftskritischen Transaktionen in Banken, Versicherungen, im Handel und in der öffentlichen Verwaltung. Wo diese Systeme laufen, laufen sie mit JCL – und weil Migrationen aufwendig und riskant sind, bleibt der Bestand über viele Jahre erhalten. Aussagen über exakte Marktanteile oder Transaktionsvolumina sind mit Vorsicht zu genießen und sollten am aktuellen Stand geprüft werden; unbestritten ist jedoch die anhaltende Präsenz dieser Systeme in kritischen Bereichen.
Man könnte meinen, JCL sei ausschließlich ein Thema für Großkonzerne mit eigenem Rechenzentrum. In der Praxis begegnet uns das Thema jedoch auch bei mittelständischen Unternehmen – etwa, wenn ein Betrieb historisch gewachsene Kernsysteme auf einem Großrechner betreibt, an einen Mainframe-Dienstleister angebunden ist oder mit Partnern und Behörden zusammenarbeitet, deren Verfahren auf dieser Technik beruhen. Selbst wer selbst keinen Mainframe betreibt, kann über Schnittstellen, Abrechnungsverfahren oder Datenlieferungen mittelbar mit dieser Welt in Berührung kommen.
Hinzu kommt die Fachkräftefrage: Das Wissen um JCL und die Mainframe-Welt konzentriert sich auf eine Generation von Fachleuten, die zunehmend in den Ruhestand geht. Für Unternehmen, deren Bestandssysteme auf dieser Technik beruhen, ist der Umgang mit diesem Know-how-Risiko eine strategische Aufgabe – unabhängig davon, ob am Ende Modernisierung, Betriebsübergabe oder geordnete Weiterführung stehen. Genau diese Einordnung ist Ziel dieses Artikels.
Die wichtigste Kategorisierung von JCL ist zugleich die am häufigsten missverstandene. JCL steht zwar in einer Kategorie mit dem Titel „Programmiersprachen“, ist aber im engeren Sinn keine solche. Sie besitzt keine Variablen im gewohnten Sinn, keine Rechenoperationen, keine frei formulierbaren Schleifen und keine echte Algorithmik. Ihr Zweck ist ein anderer: Sie beschreibt, welche fertigen Programme mit welchen Daten und Betriebsmitteln in welcher Reihenfolge ausgeführt werden. Man kann sich JCL als das Drehbuch vorstellen, während die eigentlichen Schauspieler – die COBOL-, PL/I- oder Assembler-Programme – die inhaltliche Arbeit verrichten.
Diese Rollentrennung ist bewusst und sinnvoll. Sie entkoppelt die fachliche Logik eines Programms von den konkreten Daten und der Umgebung, in der es läuft. Dasselbe Programm kann so über unterschiedliche JCL mit unterschiedlichen Datenbeständen betrieben werden, ohne selbst verändert zu werden. Für den Betrieb großer, standardisierter Verarbeitungsketten ist das ein Vorteil – auch wenn es dazu führt, dass die Steuerung getrennt vom Programm gepflegt werden muss und beide zusammenpassen müssen.
JCL ist überwiegend deklarativ: Man beschreibt gewünschte Zustände und Zuordnungen, statt einen Ablauf Schritt für Schritt zu programmieren. Diese Beschreibung ist knapp, formal und wenig fehlertolerant – eine falsch gesetzte Angabe oder ein vergessener Verweis führt schnell zum Abbruch. Zugleich ist genau diese Strenge im Massenbetrieb ein Vorteil: Was einmal korrekt formuliert ist, läuft reproduzierbar und ohne Überraschungen, Nacht für Nacht.
Die begrenzte Ablauflogik von JCL – im Wesentlichen das bedingte Ausführen oder Überspringen von Schritten anhand von Rückgabewerten – ist bewusst schlank gehalten. Komplexere Steuerung überlässt man in der Praxis entweder den Programmen selbst oder übergeordneten Werkzeugen wie Job-Schedulern, auf die wir später eingehen. JCL will nicht alles können; sie will die eine Aufgabe – Programme geordnet mit Ressourcen versorgen und ausführen – zuverlässig erledigen.
Ein JCL-Ablauf ist als Job organisiert, der aus einem oder mehreren Job-Schritten besteht. Jeder Schritt ruft ein Programm oder eine Vorlage auf und bekommt die Daten zugewiesen, die er benötigt. Auffällig ist die formale Gestalt: Anweisungen beginnen am Zeilenanfang mit zwei Schrägstrichen, sind spaltenorientiert, werden in Großbuchstaben geschrieben und folgen einem festen Aufbau aus Name, Operation und Parametern. Diese Strenge wirkt heute antiquiert, ist aber Erbe der Lochkarten-Ära und sorgt zugleich für eindeutige, maschinell gut verarbeitbare Anweisungen.
Die gesamte Grundmechanik von JCL lässt sich an drei Anweisungstypen erklären, die den Kern jeder Job-Beschreibung bilden:
Dieses Zusammenspiel ist das Herz von JCL: JOB rahmt den Auftrag, EXEC benennt die auszuführenden Programme, DD versorgt sie mit Daten und Betriebsmitteln. Alles Weitere – Prozeduren, bedingte Ausführung, Kommentare, symbolische Parameter – baut auf diesem Grundgerüst auf. Wer diese drei Bausteine begriffen hat, kann eine JCL im Groben lesen, auch ohne die Feinheiten der Parameter zu kennen.
Ein für Außenstehende zunächst ungewohntes Konzept ist die Art, wie auf dem Mainframe Datenbestände benannt und angesprochen werden. Dateien – in dieser Welt meist als Datasets bezeichnet – tragen strukturierte, mehrteilige Namen und werden über einen zentralen Katalog verwaltet, der weiß, wo ein Datenbestand physisch liegt. Die DD-Anweisungen der JCL greifen auf diese Namen zurück. Das erlaubt es, Programme unabhängig vom konkreten Speicherort zu halten: Verschiebt sich ein Datenbestand physisch, muss idealerweise nur der Katalog stimmen, nicht jedes einzelne Programm.
Diese Entkopplung ist elegant, hat aber eine Kehrseite: Sie setzt sauber gepflegte Namenskonventionen und einen konsistenten Katalog voraus. In gewachsenen Umgebungen ist die Menge der Datenbestände und ihrer Namen enorm, und die Beziehungen zwischen Jobs, Programmen und Daten sind entsprechend verflochten. Ein wesentlicher Teil der Betriebsarbeit besteht darin, diese Ordnung zu wahren – ein Aspekt, auf den wir im Betriebskapitel zurückkommen.
Damit nicht für jeden ähnlichen Job dieselben Anweisungen neu geschrieben werden müssen, kennt JCL das Konzept der Prozeduren: vorgefertigte, wiederverwendbare Bausteine, die an zentraler Stelle abgelegt und aus konkreten Jobs heraus aufgerufen werden. Über symbolische Parameter lassen sich solche Vorlagen anpassen, ohne sie zu duplizieren – etwa, um denselben Ablauf für verschiedene Mandanten, Zeiträume oder Datenbestände zu nutzen. Das bringt einen gewissen Grad an Standardisierung und Wartbarkeit in die JCL-Landschaft.
Gleichzeitig entsteht dadurch eine indirekte Struktur, die man kennen muss, um sie zu durchschauen: Was ein Job tatsächlich tut, ergibt sich erst aus dem Zusammenspiel des aufrufenden Jobs mit der aufgerufenen Prozedur und den übergebenen Parametern. Für Einsteiger ist das eine der Hürden beim Lesen fremder JCL – und ein Grund, warum gute Dokumentation und einheitliche Konventionen in diesem Umfeld besonders wertvoll sind.
Das Betriebssystem, in dem JCL heute ihre Heimat hat, ist z/OS – der aktuelle Vertreter einer Betriebssystem-Linie, die über MVS und OS/390 bis zu den Anfängen der Großrechner zurückreicht. z/OS ist auf höchste Verfügbarkeit, Stabilität und Durchsatz bei sehr großen Transaktions- und Datenmengen ausgelegt. In diesem Umfeld ist die Stapelverarbeitung, die über JCL gesteuert wird, eine der zentralen Betriebsarten neben der transaktionsorientierten Online-Verarbeitung.
Die Annahme, Interpretation und Ausführung von Jobs übernimmt das Job Entry Subsystem, meist in einer seiner etablierten Ausprägungen. Es nimmt eingereichte Jobs entgegen, reiht sie in Warteschlangen ein, sorgt für die Zuteilung von Betriebsmitteln, steuert die Ausführung und verwaltet die Ausgaben. Man kann sich dieses Subsystem als den Verkehrsleiter vorstellen, der aus vielen gleichzeitig eingereichten Jobs einen geordneten, priorisierten Betrieb macht. JCL ist die Sprache, in der man diesem Verkehrsleiter seine Aufträge übergibt.
Ein großer Teil der praktischen Arbeit in der Batch-Welt wird nicht von eigens geschriebenen Programmen erledigt, sondern von den Dienstprogrammen, die das Betriebssystem-Umfeld mitbringt. Für viele Standardaufgaben – Datenbestände kopieren, sortieren, zusammenführen, aufräumen, drucken oder umformatieren – existieren erprobte Utilities, die über JCL aufgerufen und mit Parametern gesteuert werden. In der Praxis besteht ein erheblicher Anteil produktiver JCL aus dem geschickten Kombinieren solcher Standardwerkzeuge.
Das ist konzeptionell durchaus vergleichbar mit dem Baukastenprinzip moderner Kommandozeilen-Werkzeuge: Kleine, spezialisierte Programme werden zu einer Verarbeitungskette verbunden. Der Unterschied liegt in der Umgebung und in der Reife dieser Werkzeuge, die über Jahrzehnte für den Massenbetrieb optimiert wurden. Für ein Unternehmen bedeutet das: Vieles muss nicht selbst programmiert werden, sondern lässt sich mit bewährten Bordmitteln erledigen – vorausgesetzt, das Wissen um diese Werkzeuge ist vorhanden.
Rund um JCL hat sich über die Jahrzehnte ein Kranz an Werkzeugen etabliert. Für die Erstellung und Bearbeitung dienen klassische Terminal-basierte Umgebungen mit Editoren und Menüsystemen; daneben gibt es modernere, grafische Entwicklungsumgebungen, die den Zugang zur Mainframe-Welt erleichtern und JCL komfortabler bearbeitbar machen. Für den Betrieb kommen Werkzeuge zur Überwachung der Warteschlangen, zur Auswertung der Job-Ausgaben und zur Fehlersuche hinzu.
Eine besondere Rolle spielen Job-Scheduler: übergeordnete Systeme, die festlegen, welcher Job wann, in welcher Reihenfolge und in welcher Abhängigkeit von anderen Jobs ausgeführt wird. Während JCL den einzelnen Auftrag beschreibt, orchestriert der Scheduler das Zusammenspiel Tausender Jobs über den Tag und die Nacht hinweg. Diese Arbeitsteilung – JCL für den einzelnen Job, der Scheduler für die Gesamtchoreografie – ist ein zentraler Baustein des Mainframe-Betriebs und ein wichtiger Anknüpfungspunkt für Modernisierung, wie wir später zeigen.
Wenn ein einzelnes Szenario JCL erklärt, dann ist es der nächtliche Batch-Lauf. In vielen Unternehmen laufen zwischen dem Ende des Tagesgeschäfts und dem nächsten Morgen umfangreiche Verarbeitungsketten ab: Buchungen des Tages werden verarbeitet, Salden fortgeschrieben, Berichte erstellt, Daten an andere Systeme übergeben, Sicherungen gezogen. Diese Läufe sind oft geschäftskritisch – wenn sie nicht rechtzeitig fertig werden, verzögert sich der Start des nächsten Geschäftstags. JCL beschreibt jeden einzelnen dieser Jobs, während der Scheduler die Gesamtchoreografie über die Nacht steuert.
Der Wert von JCL liegt hier in Verlässlichkeit und Wiederholbarkeit. Ein einmal sauber eingerichteter Job läuft Nacht für Nacht identisch, ohne dass jemand eingreifen muss. Genau diese Eigenschaft – planbarer, unbeaufsichtigter Massenbetrieb – ist der Grund, warum diese Technik in ihrer Domäne so schwer zu ersetzen ist und warum Unternehmen sie über Jahrzehnte behalten.
Neben den großen fachlichen Läufen entsteht viel praktischer Nutzen ganz unspektakulär durch das Verketten mitgelieferter Dienstprogramme. Datenbestände kopieren, sortieren, filtern, zusammenführen oder in ein anderes Format bringen – solche wiederkehrenden Aufgaben lassen sich mit erprobten Bordmitteln erledigen, gesteuert über wenige JCL-Anweisungen. Das spart eigene Programmierung und nutzt Werkzeuge, die für den Massenbetrieb ausgereift sind.
Wichtig ist auch hier die Disziplin: Über die Jahre entstehen in gewachsenen Umgebungen sehr viele solcher Jobs, und ohne klare Ordnung wird die JCL-Landschaft schnell unübersichtlich. Aus einer nützlichen Sammlung von Hilfsjobs kann sonst ein schwer durchschaubarer Bestand werden, den nur noch wenige verstehen – ein Risiko, das wir im Betriebs- und Mittelstandskapitel vertiefen.
Auf den ersten Blick ähneln sich JCL und Shell-Skripte wie Bash: Beide sind Steuer- und Skriptsprachen, die Programme aufrufen, mit Daten versorgen und zu Abläufen verketten, statt selbst die eigentliche fachliche Arbeit zu leisten. In dieser Grundrolle – als Klebstoff und Regieanweisung zwischen Programmen – sind sie tatsächlich verwandt, und wer die eine Welt kennt, versteht das Grundprinzip der anderen schnell.
Die Unterschiede sind jedoch erheblich. Shell-Skripte sind auf Unix- und Linux-Systemen zu Hause, prozedural und sehr flexibel, mit echten Variablen, Schleifen und Verzweigungen. JCL ist deklarativer, formal strenger und tief mit den spezifischen Diensten des Mainframes verzahnt. Bash-Skripte laufen typischerweise interaktiv oder als schlanke Automatisierung auf verteilten Systemen; JCL ist auf den planbaren Massen-Batch eines Großrechners ausgelegt. Man kann sie nicht ineinander übersetzen, ohne zugleich die dahinterliegende Betriebsumgebung mitzudenken.
Ein zweiter häufiger Vergleich ist der mit modernen Job-Schedulern. Hier ist Vorsicht geboten, weil beide unterschiedliche Ebenen bedienen. JCL beschreibt den einzelnen Job – welche Programme mit welchen Daten laufen. Ein Scheduler beschreibt dagegen die Choreografie vieler Jobs: wann sie starten, in welcher Reihenfolge, in welcher Abhängigkeit voneinander und wie auf Fehler reagiert wird. In der Praxis arbeiten beide zusammen; der Scheduler ruft die per JCL beschriebenen Jobs zum richtigen Zeitpunkt und in der richtigen Reihenfolge auf.
Moderne, plattformübergreifende Scheduler und Workflow-Werkzeuge übernehmen zunehmend die Rolle der übergeordneten Orchestrierung – auch über die Grenzen des Mainframes hinaus, wenn Abläufe verschiedene Systemwelten verbinden. Für die Zukunft ist das ein wichtiger Ansatzpunkt: Nicht selten bleibt die per JCL beschriebene Verarbeitung zunächst bestehen, während die Steuerung darüber schrittweise in modernere Orchestrierungswerkzeuge verlagert wird. Diese Trennung von einzelnem Job und übergeordneter Steuerung ist ein zentrales Motiv im Zukunftskapitel.
Im Umfeld von Datenplattformen und Cloud-Diensten haben sich Werkzeuge zur Workflow-Orchestrierung etabliert, die Abläufe als reichhaltige, oft in einer modernen Sprache beschriebene Ketten von Aufgaben modellieren – mit feingranularer Ablauflogik, Wiederholungsstrategien, Überwachung und Visualisierung. Gemessen an ihrer Ausdruckskraft für komplexe, verteilte Abläufe sind diese Werkzeuge JCL weit voraus.
Umgekehrt sind sie kein direkter Ersatz für die tief in den Mainframe integrierte, über Jahrzehnte gehärtete Batch-Maschinerie samt ihrer Dienstprogramme und ihrer Nähe zu den geschäftskritischen Kernsystemen. Die ehrliche Einordnung lautet daher: Für neue, verteilte Datenworkflows greift man zu modernen Orchestrierungswerkzeugen; für den bestehenden, geschäftskritischen Mainframe-Batch bleibt JCL vorerst der etablierte Weg, dessen Ablösung sorgfältig geplant sein will.
Die formale Strenge von JCL ist Stärke und Schwäche zugleich. Weil Anweisungen spaltenorientiert, groß geschrieben und exakt aufgebaut sein müssen, führt schon eine kleine Abweichung – ein falsch gesetztes Zeichen, ein vergessener Verweis, ein Tippfehler in einem Namen – zum Abbruch des Jobs. Für Einsteiger ist das frustrierend, weil die Fehlermeldungen knapp und wenig selbsterklärend wirken. Erfahrene Betreiber lesen sie dagegen wie eine vertraute Sprache und erkennen den Fehlertyp oft auf einen Blick.
In der Praxis heißt das: JCL-Betrieb lebt von Sorgfalt und Erfahrung. Ein Großteil der typischen Fehler ist formaler Natur und ließe sich durch saubere Vorlagen, Prüfwerkzeuge und Konventionen vermeiden. Deshalb setzen gut geführte Rechenzentren stark auf standardisierte Prozeduren, damit möglichst wenig frei und damit fehleranfällig geschrieben werden muss.
Aus der Betriebspraxis lassen sich einige typische Problemfelder benennen, ohne konkrete Codebeispiele zu bemühen:
Die Fehlersuche im Batch-Betrieb stützt sich auf die ausführlichen Protokoll- und Ausgabedaten, die jeder Job hinterlässt. Aus diesen lässt sich in der Regel genau nachvollziehen, welcher Schritt mit welchem Ergebnis lief und wo es hakte. Das erfordert allerdings Übung im Lesen dieser Ausgaben – eine Kernkompetenz erfahrener Mainframe-Betreiber, die nicht ohne Weiteres ersetzbar ist.
Der wichtigste Hebel für einen stabilen Betrieb ist Disziplin: einheitliche Namenskonventionen, standardisierte und geprüfte Prozeduren, saubere Versionierung der JCL, kontrollierte Änderungsprozesse und eine gute Dokumentation der Job-Ketten und ihrer Abhängigkeiten. Wo diese Grundlagen fehlen, wird der Betrieb mit jeder Änderung riskanter und das implizite Wissen einzelner Personen zum kritischen Engpass – ein Thema, das direkt in die Mittelstands- und Fachkräftefrage führt.
Wenn wir JCL bei mittelständischen Unternehmen antreffen, dann selten als bewusste Neuentscheidung, sondern als Teil eines gewachsenen Bestands. Typische Konstellationen sind ein historisch etabliertes Kernsystem auf einem eigenen oder gemieteten Großrechner, die Anbindung an einen Mainframe-Dienstleister oder Verbund, oder die Zusammenarbeit mit Partnern und Behörden, deren Verfahren auf dieser Technik beruhen. In all diesen Fällen ist JCL kein Selbstzweck, sondern die Steuerschicht kritischer Abläufe, die seit Jahren zuverlässig laufen.
Für diese Unternehmen ist die Ausgangslage zwiespältig. Einerseits funktionieren die Systeme, sind stabil und erprobt, und ein Austausch wäre teuer und riskant. Andererseits schwindet das Wissen um ihre Pflege, die Technik gilt vielen jüngeren Mitarbeitern als fremd, und die Abhängigkeit von wenigen erfahrenen Personen wächst. Diese Spannung – bewährter Betrieb bei zugleich steigendem Know-how-Risiko – prägt fast alle unsere Gespräche zum Thema.
Das wichtigste Thema rund um JCL im Mittelstand ist nicht technischer, sondern personeller Natur. Das Wissen um Mainframe-Betrieb, JCL und die zugehörigen Kernsysteme konzentriert sich auf eine erfahrene Generation von Fachleuten, die vielerorts das Renteneintrittsalter erreicht oder bereits überschritten hat. Gleichzeitig wird diese Technik in der Ausbildung deutlich seltener vermittelt als moderne, offene Plattformen. Die Folge ist eine Schere: Der Bedarf an Wissensträgern besteht fort, der Nachwuchs wird knapper.
Für ein mittelständisches Unternehmen bedeutet das ein konkretes Betriebsrisiko. Wenn kritische Abläufe von einzelnen Personen abhängen und dieses Wissen nicht dokumentiert und weitergegeben wird, entsteht eine gefährliche Abhängigkeit. Der Ausfall oder Weggang weniger Schlüsselpersonen kann dann den geordneten Betrieb geschäftskritischer Läufe gefährden. Diese Wissenskonzentration ehrlich zu benennen und aktiv anzugehen, gehört zu einer verantwortungsvollen IT-Strategie.
Der Umgang mit dieser Lage folgt keiner Einheitslösung, aber einigen bewährten Prinzipien. Zuerst steht die Wissenssicherung: Die vorhandenen Job-Ketten, ihre Abhängigkeiten, die genutzten Prozeduren und die betrieblichen Besonderheiten sollten dokumentiert werden, solange die erfahrenen Wissensträger noch verfügbar sind. Dieses Wissen ist oft nur in Köpfen vorhanden und geht mit dem Ausscheiden dieser Personen unwiederbringlich verloren.
Parallel lohnt eine nüchterne strategische Einordnung: Welche Rolle sollen die Bestandssysteme mittelfristig spielen? Wird der Betrieb weitergeführt, an einen spezialisierten Dienstleister übergeben oder schrittweise modernisiert? Jede dieser Optionen hat andere Konsequenzen für Personal, Kosten und Risiko. Wichtig ist, diese Entscheidung bewusst und rechtzeitig zu treffen und nicht durch das Ausscheiden des letzten Experten erzwingen zu lassen. Aus unserer Sicht ist die geordnete Auseinandersetzung mit diesem Thema selbst dann wertvoll, wenn am Ende die Weiterführung des Bestands steht – weil sie das Risiko sichtbar und steuerbar macht.
Die Vorstellung, den Mainframe-Batch samt JCL kurzfristig durch etwas Modernes zu ersetzen, ist in den meisten Fällen unrealistisch. Die betroffenen Systeme sind geschäftskritisch, über Jahrzehnte gewachsen und eng mit anderen Verfahren verflochten. Eine vollständige Ablösung ist ein Großvorhaben mit erheblichem Aufwand und Risiko, das sorgfältig geplant sein will. Deshalb bleibt JCL in vielen Häusern noch auf absehbare Zeit im produktiven Einsatz – nicht aus Nostalgie, sondern aus wohlverstandener Risikoabwägung.
Wandel setzt daher meist nicht am radikalen Austausch an, sondern an den Rändern und an der Steuerungsebene. Ein häufiger, pragmatischer Ansatz ist, die eigentliche Batch-Verarbeitung zunächst bestehen zu lassen und die übergeordnete Orchestrierung zu modernisieren: Statt die Job-Choreografie ausschließlich in klassischen Mainframe-Werkzeugen zu steuern, übernimmt zunehmend ein moderner, plattformübergreifender Scheduler oder ein Orchestrierungswerkzeug die Regie über die Job-Ketten – auch über Systemgrenzen hinweg.
Die Trennung zwischen dem einzelnen Job und der übergeordneten Steuerung, die wir bereits im Abgrenzungskapitel angesprochen haben, ist der entscheidende Hebel für Modernisierung. Solange die per JCL beschriebenen Jobs sauber gekapselt sind, lässt sich die Ebene darüber – wann welcher Job in welcher Abhängigkeit läuft – schrittweise in modernere Orchestrierungswerkzeuge verlagern. Das erlaubt es, Mainframe-Batch und Abläufe auf offenen Plattformen unter einer gemeinsamen, transparenteren Steuerung zusammenzuführen.
Diese Brückenstrategie hat mehrere Vorteile. Sie reduziert die Abhängigkeit von spezialisierten Altwerkzeugen an der Steuerungsebene, schafft mehr Transparenz über die Gesamtabläufe und ebnet den Weg für spätere, tiefergehende Modernisierungsschritte, ohne den laufenden Betrieb zu gefährden. Gleichzeitig verlangt sie eine gute Kenntnis der bestehenden Job-Ketten – womit sich der Kreis zur Wissenssicherung aus dem Mittelstandskapitel schließt.
Wo eine tiefergehende Modernisierung angestrebt wird, kommen unterschiedliche Wege in Betracht, die sich in Aufwand und Risiko deutlich unterscheiden. Zu den in der Praxis diskutierten Ansätzen zählen die Neu-Implementierung fachlicher Abläufe auf modernen Plattformen, das automatisierte oder manuelle Umsetzen von Batch-Logik in andere Technologien sowie hybride Modelle, in denen Mainframe und offene Systeme koexistieren. Welcher Weg passt, hängt stark von der konkreten Systemlandschaft, den Kosten, dem verfügbaren Wissen und der Risikobereitschaft ab – eine pauschale Empfehlung wäre unseriös.
Der größte Fallstrick ist die Unterschätzung der Komplexität. Was in der JCL schlank aussieht, verbirgt oft jahrzehntelang gewachsene fachliche Feinheiten, Sonderfälle und implizites Wissen. Eine Modernisierung, die diese verborgene Komplexität nicht sorgfältig erhebt, scheitert regelmäßig an genau den Details, die niemand mehr dokumentiert hatte. Deshalb steht am Anfang jeder ernsthaften Modernisierung eine gründliche Bestandsaufnahme – der aktuelle Stand von Werkzeugen, Plattformen und Anbieterangeboten sollte dabei stets geprüft werden, da sich dieses Feld laufend weiterentwickelt.
