Der historische Kontext ist wichtig, um PL/I zu verstehen. In den 1960er-Jahren gab es im Wesentlichen zwei getrennte Lager: Fortran für Ingenieure, Naturwissenschaftler und mathematisch geprägte Aufgaben, und COBOL für die kaufmännische Datenverarbeitung in Verwaltung, Handel und Finanzwesen. Wer beides brauchte, musste zwei Sprachen und zwei Werkzeugketten pflegen. PL/I trat mit dem Anspruch an, diese Trennung aufzuheben und beide Anwendungsfelder gleichermaßen gut zu bedienen – ergänzt um damals moderne Konzepte wie Nebenläufigkeit und eine ausgefeilte Ausnahmebehandlung.
Drei Eigenschaften prägen PL/I bis heute:
PL/I trat mit dem Anspruch an, die eine universelle Sprache zu werden und die Spezialisten COBOL und Fortran abzulösen. Dieses ehrgeizige Ziel hat die Sprache nicht in voller Breite erreicht. COBOL blieb im kaufmännischen Umfeld dominant, Fortran hielt sich im wissenschaftlichen Rechnen, und mit dem Aufkommen von C und später weiteren Sprachen entstand zusätzliche Konkurrenz. Dennoch fand PL/I feste, teils sehr treue Anwender – vor allem in großen Rechenzentren, die den universellen Ansatz und die Ausdrucksstärke der Sprache schätzten.
Das Ergebnis ist eine Sprache, die zwar nie zur alles beherrschenden Leitsprache wurde, sich aber in wichtigen Kernbereichen dauerhaft etabliert hat. Wer heute mit PL/I zu tun hat, begegnet ihr fast immer in Form gewachsener, geschäftskritischer Bestandssoftware, die über Jahrzehnte gepflegt und erweitert wurde und häufig im Zentrum wichtiger Geschäftsprozesse steht.
Auf den ersten Blick wirkt PL/I wie ein Thema ausschließlich für große Konzerne mit eigenen Großrechnern. Tatsächlich ist die Sprache aber auch für den Mittelstand relevant – meist indirekt. Viele mittelständische Unternehmen sind Zulieferer, Partner oder Dienstleister von Banken, Versicherungen und Behörden, deren Kernsysteme in PL/I laufen. Schnittstellen, Datenaustausch und gemeinsame Projekte berühren dann zwangsläufig die PL/I-Welt.
Hinzu kommt: Auch mittelständische Unternehmen können durch Zukäufe, historische Entscheidungen oder Branchenzugehörigkeit selbst PL/I-Bestände in ihrer IT haben. In solchen Fällen geht es selten um Neuentwicklung, sondern um Wartbarkeit, Know-how-Sicherung und die Frage, wie eine bewährte, aber alternde Codebasis langfristig tragfähig bleibt. Genau diese strategische Perspektive ist das Ziel dieses Artikels.
Das prägendste Merkmal von PL/I ist der bewusste Verzicht auf Spezialisierung. Wo COBOL die kaufmännische Datenverarbeitung und Fortran das numerische Rechnen jeweils optimal bedienen wollten, strebte PL/I danach, beides gut genug zu können und darüber hinaus systemnahe und nebenläufige Aufgaben zu unterstützen. Diese Universalität ist die zentrale Designentscheidung, aus der sich fast alle anderen Eigenschaften ableiten.
Der Preis dieser Breite ist Umfang. PL/I gilt als große Sprache mit vielen Sprachmitteln, zahlreichen Voreinstellungsregeln und einer beträchtlichen Zahl an eingebauten Funktionen. Für erfahrene Entwickler ist das ein mächtiges Werkzeug, für Einsteiger eine hohe Hürde. In der Praxis nutzen die meisten Programme ohnehin nur einen Teil des Sprachumfangs, was den Einstieg in eine bestehende Codebasis erleichtert – vorausgesetzt, der genutzte Stil ist konsistent.
Ein Merkmal, das PL/I für das Finanzwesen bis heute wertvoll macht, ist das reiche Typsystem mit exakter Dezimalarithmetik. Geldbeträge und kaufmännische Berechnungen verlangen exaktes Rechnen ohne die Rundungseffekte, die bei binärer Gleitkommaarithmetik auftreten. PL/I bietet dafür feste Dezimaltypen mit einstellbarer Genauigkeit – ein Grund, warum die Sprache in Banken und Versicherungen so gut passte und warum entsprechender Code dort besonders langlebig ist.
Hinzu kommen strukturierte Datentypen, mit denen sich komplexe Datensätze – etwa ein vollständiger Vertrags- oder Kontosatz – als zusammengesetzte Struktur abbilden lassen, sowie Zeiger und dynamische Speicherverwaltung für anspruchsvollere, systemnahe Aufgaben. Diese Kombination aus kaufmännischer Präzision und technischer Flexibilität ist das, was den universellen Anspruch der Sprache in der Praxis konkret einlöst.
Ein Programm in PL/I ist aus Blöcken und Prozeduren aufgebaut. Das Hauptprogramm ist selbst eine Prozedur, die weitere Prozeduren und interne Blöcke enthalten kann. Jeder Block definiert einen Gültigkeitsbereich für die darin vereinbarten Variablen. Diese Blockstruktur war ein Fortschritt gegenüber der linearen Organisation älterer Sprachen und erlaubt eine klare, modulare Gliederung – vorausgesetzt, die Entwickler nutzen sie diszipliniert. Anweisungen werden durch Semikolons abgeschlossen, und das Quelltextformat ist weitgehend frei, ohne die starre Spaltenbindung mancher Zeitgenossen.
Variablen werden in PL/I mit einer Deklaration eingeführt, in der sich über Attribute sehr genau festlegen lässt, welchen Typ, welche Genauigkeit und welche Speicherform eine Größe hat. Diese Attributvielfalt ist ein Kennzeichen der Sprache: Sie erlaubt eine feine Kontrolle, verlangt aber auch Sorgfalt. Berüchtigt sind die umfangreichen Voreinstellungsregeln, nach denen PL/I fehlende Attribute selbstständig ergänzt. Das ist bequem, kann aber bei Unachtsamkeit zu überraschendem Verhalten führen. In der professionellen Wartung gilt daher die Faustregel, wichtige Attribute lieber explizit anzugeben, statt sich auf Voreinstellungen zu verlassen.
Gerade dieser Punkt ist für den Umgang mit Bestandscode wichtig. Wer eine gewachsene PL/I-Codebasis übernimmt, muss die Voreinstellungsregeln kennen, um das tatsächliche Verhalten des Programms sicher zu verstehen. Ein oberflächliches Lesen genügt hier oft nicht – ein Grund, warum fundiertes PL/I-Wissen bei der Wartung so wertvoll ist.
Ein für seine Entstehungszeit fortschrittliches Merkmal ist die integrierte Ausnahmebehandlung. PL/I kennt das Konzept von Bedingungen, die bei bestimmten Ereignissen ausgelöst werden – etwa beim Erreichen des Dateiendes, bei einem arithmetischen Überlauf oder bei einer Division durch null. Für solche Bedingungen lassen sich eigene Behandlungsroutinen hinterlegen, sodass das Programm gezielt und kontrolliert auf Ausnahmesituationen reagieren kann, statt einfach abzubrechen.
Dieses Konzept nimmt vieles vorweg, was heutige Sprachen über Ausnahmemechanismen bieten. In der Praxis ist die Behandlung von Bedingungen in PL/I mächtig, aber auch fehleranfällig, wenn sie unstrukturiert eingesetzt wird – etwa wenn der Programmablauf über viele verstreute Bedingungsbehandlungen springt und dadurch schwer nachvollziehbar wird. Sauber und einheitlich genutzt, trägt sie jedoch erheblich zur Robustheit der oft geschäftskritischen Programme bei.
PL/I ist bewusst ausdrucksstark: Viele Operationen, etwa auf ganzen Feldern oder Zeichenketten, lassen sich kompakt formulieren, und die große Zahl eingebauter Funktionen nimmt dem Entwickler viel Arbeit ab. Das macht gut geschriebenen PL/I-Code dicht und leistungsfähig. Die Kehrseite ist, dass diese Dichte in Verbindung mit dem freien Format und den Voreinstellungsregeln auch schwer lesbaren Code hervorbringen kann, wenn keine Konventionen eingehalten werden.
Für die Bestandspflege bedeutet das: Die Qualität einer PL/I-Codebasis hängt stark davon ab, wie diszipliniert sie über die Jahre gepflegt wurde. Gut strukturierte, konsistent kommentierte PL/I-Programme sind auch nach Jahrzehnten wartbar; historisch gewachsener, uneinheitlicher Code kann dagegen zur echten Herausforderung werden. Welche konkreten Sprachfeatures in einer bestimmten Compiler-Version zur Verfügung stehen, sollte stets anhand der jeweils maßgeblichen Herstellerdokumentation geprüft werden.
Die natürliche Umgebung von PL/I ist der IBM-Großrechner unter dem Betriebssystem z/OS. Dort werden PL/I-Programme kompiliert, gebunden und ausgeführt – häufig in einem Zusammenspiel mit anderen Sprachen wie COBOL und Assembler, die auf demselben System koexistieren. Der Großrechner ist eine über Jahrzehnte optimierte Plattform für die zuverlässige Verarbeitung sehr großer Datenmengen mit hohen Anforderungen an Verfügbarkeit, Durchsatz und Datenintegrität. Genau in diesem Umfeld spielt PL/I seine Stärken aus.
Die maßgebliche moderne Umsetzung ist der IBM Enterprise PL/I für z/OS, ein aktiv gepflegter Compiler, der die Sprache auf aktuellen Großrechner-Generationen unterstützt und um moderne Fähigkeiten erweitert. Daneben existieren PL/I-Umsetzungen für andere Plattformen und von anderen Anbietern; deren Verfügbarkeit, Sprachumfang und Kompatibilität sind im Einzelfall zu prüfen. Für die weit überwiegende Zahl produktiver PL/I-Bestände ist jedoch das z/OS-Umfeld der maßgebliche Kontext.
PL/I-Programme stehen nie für sich allein, sondern sind in eine größere Systemlandschaft eingebettet. Im Stapelbetrieb steuert eine Auftrags- und Steuersprache, wie Programme ausgeführt werden, welche Dateien sie verwenden und in welcher Reihenfolge Verarbeitungsschritte ablaufen. Für die interaktive, transaktionsorientierte Verarbeitung sind PL/I-Programme häufig in einen Transaktionsmonitor eingebunden, der gleichzeitige Zugriffe vieler Nutzer koordiniert. Und die Daten selbst liegen typischerweise in hierarchischen oder relationalen Großrechner-Datenbanken oder in speziellen Dateisystemen.
Für das Verständnis eines PL/I-Systems ist diese Einbettung zentral: Der eigentliche PL/I-Code ist oft nur ein Teil des Gesamtbildes. Wer eine solche Landschaft warten oder modernisieren will, muss die umgebenden Bausteine – Job-Steuerung, Transaktionsmonitor, Datenbank – mitdenken. Ein isolierter Blick auf die Sprache greift zu kurz und ist eine häufige Ursache für unterschätzten Aufwand in Modernisierungsprojekten.
Traditionell wurde PL/I in der klassischen Großrechner-Entwicklungsumgebung bearbeitet – mit textbasierten Editoren und Werkzeugen, die eng mit dem Betriebssystem verzahnt sind. Diese Werkzeuge sind für erfahrene Mainframe-Entwickler hocheffizient, wirken auf Umsteiger aus der modernen Anwendungsentwicklung jedoch ungewohnt. In den letzten Jahren sind Brücken zu zeitgemäßen Entwicklungsumgebungen entstanden, die es erlauben, PL/I-Code auch in grafischen, integrierten Werkzeugen zu bearbeiten und mit modernen Abläufen zu verbinden.
Diese Modernisierung der Werkzeugkette ist für die Zukunftsfähigkeit wichtig, denn sie senkt die Einstiegshürde für jüngere Entwickler, die mit klassischen Großrechner-Werkzeugen nicht mehr aufgewachsen sind. Welche Werkzeuge im Einzelfall verfügbar und sinnvoll sind, hängt stark von der konkreten Systemlandschaft und den eingesetzten Produktversionen ab und sollte projektbezogen bewertet werden.
Wenn ein Feld die heutige Bedeutung von PL/I erklärt, dann ist es das Finanzwesen. Banken und Versicherungen haben über Jahrzehnte hochkomplexe Fachlogik in PL/I abgebildet – Berechnungsregeln, Bestandsführung, Abrechnungsläufe, regulatorische Anforderungen. Diese Systeme sind das digitale Gedächtnis und das Rechenwerk der Institute; sie funktionieren zuverlässig und verarbeiten Tag für Tag enorme Volumina. Eine leichtfertige Ablösung verbietet sich schon deshalb, weil das Risiko für das laufende Geschäft immens wäre.
Der Wert dieser Systeme liegt weniger in der Sprache selbst als in der über Jahrzehnte akkumulierten, oft nirgends vollständig dokumentierten Fachlogik. Genau darin liegt die Herausforderung jeder Modernisierung: Nicht der Code an sich ist das Problem, sondern das in ihm eingefrorene Fachwissen, das bei einer Ablösung vollständig verstanden und übertragen werden muss. Diesen Aspekt vertiefen wir im Modernisierungs-Kapitel.
Neben der prestigeträchtigen Fachlogik liegt ein großer, oft unsichtbarer Nutzen von PL/I in der schieren Verarbeitungskraft im Stapelbetrieb. Die nächtlichen Läufe, in denen Kontostände fortgeschrieben, Abrechnungen erstellt oder Bestände aktualisiert werden, sind das unspektakuläre Rückgrat vieler Institute. PL/I ist für diese Aufgaben gebaut: kompilierter, effizienter Code, der in Verbindung mit der Großrechner-Architektur sehr große Datenmengen zuverlässig und in engen Zeitfenstern abarbeitet.
Diese Läufe sind selten sichtbar, aber unternehmenskritisch: Verzögert sich ein nächtlicher Verarbeitungslauf, kann das den Geschäftsbetrieb des Folgetags gefährden. Genau deshalb ist die Stabilität und Vorhersagbarkeit, die PL/I auf dem Großrechner bietet, ein Wert an sich – und ein wichtiger Grund, warum Unternehmen bei einer Ablösung so vorsichtig vorgehen müssen.
COBOL ist die dominierende Sprache der kaufmännischen Datenverarbeitung auf dem Großrechner und damit der wichtigste Vergleichspunkt für PL/I. Beide Sprachen bedienen weitgehend dasselbe Umfeld – geschäftskritische Bestandssysteme in Banken, Versicherungen und Verwaltung. Der Unterschied liegt im Charakter: COBOL ist bewusst auf kaufmännische Aufgaben zugeschnitten, sehr wortreich und in seiner klassischen Form spaltengebunden, was den Code lang, aber auch sehr lesbar macht. PL/I ist universeller, kompakter und ausdrucksstärker, dafür aber komplexer.
In der Verbreitung hat COBOL PL/I deutlich überflügelt: Der Bestand an COBOL-Code auf Großrechnern ist erheblich größer, und auch der Markt für COBOL-Know-how ist – bei aller Knappheit – größer als der für PL/I. Für Unternehmen mit PL/I-Beständen bedeutet das eine zusätzliche Herausforderung, weil das ohnehin schrumpfende Fachwissen bei PL/I noch spezialisierter und schwerer zu finden ist. Diesen Punkt greifen wir im Status- und im Modernisierungs-Kapitel auf.
Fortran ist die klassische Sprache des wissenschaftlich-technischen Rechnens, optimiert auf numerische Berechnungen und mathematische Aufgaben. PL/I trat mit dem Anspruch an, auch dieses Feld abzudecken, und bietet für numerisches Rechnen leistungsfähige Mittel. In der Praxis hat sich Fortran in seiner Kerndomäne dennoch behauptet, weil es dort tief verwurzelt, kompakt und über spezialisierte Bibliotheken hochoptimiert ist.
Die Abgrenzung verdeutlicht das grundsätzliche Dilemma von PL/I: Der universelle Ansatz macht die Sprache in vielen Bereichen gut, aber in kaum einem Bereich unangefochten am besten. Wo Anwender die absolute Spezialisierung suchten, blieben sie bei Fortran; wo sie ein einziges Werkzeug für gemischte Aufgaben wollten, war PL/I attraktiv. Beide Perspektiven haben ihre Berechtigung, was die dauerhafte Koexistenz der Sprachen erklärt.
C entstand später als PL/I und in einem anderen Kontext: als schlanke, systemnahe Sprache für die Programmierung von Betriebssystemen und maschinennaher Software. C ist bewusst minimalistisch, gibt dem Entwickler viel Kontrolle und wurde zur Grundlage eines riesigen Ökosystems außerhalb der Großrechnerwelt. PL/I dagegen ist reichhaltiger, stärker auf Anwendungsentwicklung im Großrechner-Umfeld ausgerichtet und nimmt dem Entwickler mehr technische Detailarbeit ab.
Die beiden Sprachen stehen daher weniger in direkter Konkurrenz als in unterschiedlichen Welten. Interessant ist die Abgrenzung dennoch für Modernisierungsüberlegungen: Wo systemnahe, portable Programmierung gefragt ist, ist C oder eine modernere Sprache oft die naheliegende Zielrichtung – während die kaufmännische Fachlogik eines PL/I-Systems damit gerade nicht ohne Weiteres nachgebildet ist. Die Sprachwahl allein löst die eigentliche Herausforderung, die Übertragung der Fachlogik, nicht.
Der Status von PL/I lässt sich in einem Satz zusammenfassen: Es ist eine Bestandssprache im aktiven Betrieb. Neue Systeme werden praktisch nicht mehr in PL/I entwickelt, aber die vorhandene Software läuft weiter und wird gewartet, korrigiert und punktuell erweitert. In den Branchen, in denen PL/I verankert ist, verrichtet die Sprache Tag für Tag zuverlässig ihre Arbeit im Zentrum geschäftskritischer Prozesse.
Dass die Sprache nicht mehr wächst, bedeutet also nicht, dass sie verschwunden ist. Im Gegenteil: Die Bestände sind so groß, so tief in die Geschäftsprozesse eingebettet und so schwer zu ersetzen, dass sie voraussichtlich noch viele Jahre laufen werden. Der maßgebliche Compiler für das Großrechner-Umfeld wird weiterhin gepflegt und an aktuelle Systemgenerationen angepasst, was die Zukunftsfähigkeit des Betriebs technisch absichert. Die eigentliche Herausforderung ist daher nicht die Technik, sondern das Wissen um sie.
Das größte Risiko rund um PL/I ist nicht technischer, sondern personeller Natur. Die Entwickler, die PL/I-Systeme über Jahrzehnte aufgebaut und gepflegt haben, gehen zunehmend in den Ruhestand, und es rücken kaum jüngere Fachkräfte nach, weil PL/I in Ausbildung und Studium so gut wie keine Rolle mehr spielt. Das Ergebnis ist ein schrumpfender, alternder Pool an Spezialisten – bei gleichzeitig weiterhin bestehendem Wartungsbedarf.
Dieser demografische Effekt ist das eigentliche Kernproblem. Solange erfahrene Entwickler verfügbar sind, lassen sich PL/I-Systeme sicher betreiben. Verlässt dieses Wissen jedoch unkontrolliert das Unternehmen, entsteht ein gefährliches Vakuum: Systeme, die niemand mehr vollständig versteht, aber die für das Geschäft unverzichtbar sind. Die frühzeitige und systematische Sicherung dieses Wissens ist deshalb keine Kür, sondern eine Notwendigkeit – ein Thema, das wir im nächsten Kapitel vertiefen.
Angesichts der Know-how-Problematik liegt die Frage nahe, warum die Systeme nicht längst abgelöst wurden. Die Antwort liegt in einer Kombination aus Risiko, Aufwand und Bewährtheit. Die Systeme funktionieren zuverlässig, verarbeiten enorme Volumina und bilden über Jahrzehnte gewachsene, komplexe Fachlogik ab, die oft nicht vollständig dokumentiert ist. Eine Ablösung bedeutet, dieses gesamte Wissen zu rekonstruieren und in einer neuen Umgebung fehlerfrei nachzubilden – bei laufendem Betrieb und ohne das Geschäft zu gefährden.
Solche Vorhaben sind teuer, langwierig und risikobehaftet. Viele Unternehmen entscheiden sich deshalb bewusst dafür, bewährte Kernsysteme zunächst weiterzubetreiben und stattdessen die Ränder zu modernisieren – etwa moderne Zugangskanäle und Schnittstellen vor den stabilen Kern zu setzen. Dieser pragmatische Ansatz verschafft Zeit, löst das Grundproblem aber nicht, sondern verschiebt es. Eine seriöse Strategie muss beides im Blick haben: den sicheren Weiterbetrieb heute und einen realistischen Modernisierungspfad für morgen.
Unabhängig davon, ob ein Unternehmen an Ablösung, Modernisierung oder reinem Weiterbetrieb denkt, ist die Sicherung des Fachwissens die dringlichste Aufgabe. Solange erfahrene Entwickler verfügbar sind, sollte ihr Wissen systematisch dokumentiert werden: Wie sind die Systeme aufgebaut, welche Fachlogik steckt in den Programmen, welche Konventionen und ungeschriebenen Regeln gelten, wie hängen die Bausteine zusammen. Dieses Wissen ist der wertvollste und zugleich flüchtigste Bestandteil einer PL/I-Landschaft.
In der Praxis empfiehlt sich eine Kombination aus Dokumentation, gezielter Wissensweitergabe an jüngere Kräfte und – wo möglich – der Nutzung von Werkzeugen, die den Code und seine Zusammenhänge analysieren und sichtbar machen. Wichtig ist der Zeitpunkt: Wissenssicherung muss beginnen, solange die Fachleute noch im Unternehmen sind. Erst zu handeln, wenn der letzte Experte in den Ruhestand geht, ist ein häufig unterschätztes und teuer bezahltes Versäumnis.
Für den sicheren Weiterbetrieb einer PL/I-Landschaft gelten dieselben Grundsätze guter Softwarepflege wie anderswo, nur unter erschwerten Bedingungen. Der Code sollte versioniert und geordnet abgelegt sein, Änderungen sollten nachvollziehbar dokumentiert und getestet werden, und es sollte klare Verantwortlichkeiten geben. Wo die Werkzeugkette modernisiert werden kann – etwa durch die Anbindung zeitgemäßer Entwicklungsumgebungen –, senkt das die Hürde für jüngere Entwickler und macht die Arbeit an den Systemen attraktiver.
Ein realistischer Blick gehört dazu: Ohne verfügbares Fachwissen ist selbst gut gepflegter PL/I-Code schwer wartbar, weil die eingebettete Fachlogik ohne Erklärung schwer zu durchdringen ist. Deshalb greifen Wartbarkeit und Wissenssicherung ineinander. Investitionen in Dokumentation, Tests und moderne Werkzeuge zahlen sich nur dann voll aus, wenn parallel dafür gesorgt wird, dass Menschen die Systeme verstehen und dieses Verständnis weitergeben.
Für die Modernisierung von PL/I-Systemen gibt es keinen Königsweg, sondern ein Spektrum an Optionen mit sehr unterschiedlichen Chancen und Risiken. Ohne Empfehlung für den Einzelfall lassen sich die grundsätzlichen Richtungen skizzieren:
Welcher Weg der richtige ist, hängt von Faktoren wie Größe und Zustand der Codebasis, verfügbarem Wissen, Budget, Risikobereitschaft und strategischer Bedeutung des Systems ab. Entscheidend ist, dass die Wahl bewusst, mit ehrlicher Aufwands- und Risikoabschätzung und nicht unter Zeitdruck getroffen wird. Automatische Umsetzungs- und Analysewerkzeuge können unterstützen, ersetzen aber nicht das Verständnis der Fachlogik.
PL/I ist eine über Jahrzehnte erprobte, außerordentlich stabile Sprache. Was sich über so lange Zeit im produktiven Einsatz bewährt hat, ist technisch ausgereift und in seinem Verhalten sehr gut verstanden – zumindest von jenen, die es kennen. Die Sprache wurde zudem früh standardisiert, was ihr eine formale Grundlage jenseits einzelner Hersteller gab. In der Praxis ist jedoch die konkrete Compiler-Umsetzung für das Großrechner-Umfeld der maßgebliche Bezugspunkt, weil dort die produktiven Bestände laufen.
Diese Reife ist für Unternehmen ein zweischneidiges Argument. Einerseits spricht sie für Verlässlichkeit: PL/I-Systeme sind keine Experimente, sondern bewährte Arbeitspferde. Andererseits bedeutet Reife im Falle von PL/I auch Alter – eine Sprache am Ende ihres Lebenszyklus, deren Ökosystem an Wissen und Ausbildung schrumpft. Beide Seiten gehören zu einer ehrlichen Bewertung, und beide fließen in eine tragfähige Zukunftsstrategie ein.
Beim Thema Sicherheit ist zwischen der Sprache und ihrem Umfeld zu unterscheiden. Der Großrechner gilt als eine der robustesten und am stärksten abgesicherten Plattformen überhaupt, mit ausgereiften Mechanismen für Zugriffskontrolle, Datenintegrität und Betriebssicherheit. In diesem Sinne ist eine PL/I-Landschaft auf dem Großrechner in einer sehr sicheren Umgebung verankert. Sicherheitsrisiken entstehen daher seltener durch die Sprache selbst als durch das Umfeld und die Prozesse drumherum.
Die praktisch relevanten Risiken liegen häufig im Verlust von Wissen, in unzureichender Dokumentation, in fehlenden Tests bei Änderungen und in der Anbindung alter Systeme an moderne, offene Kanäle, bei der neue Angriffsflächen entstehen können. Die Gegenmaßnahmen sind entsprechend organisatorisch: klare Prozesse, saubere Zugriffskontrolle, sorgfältige Absicherung von Schnittstellen und die konsequente Wissenssicherung. Der jeweils aktuelle Stand zu Produktversionen und Sicherheitsempfehlungen sollte anhand der maßgeblichen Herstellerinformationen geprüft werden.
Strategisch ist PL/I kein Thema der Technologiewahl, sondern des Risikomanagements über einen langen Zeithorizont. Die zentrale Frage lautet, wie ein Unternehmen die Balance zwischen dem sicheren Weiterbetrieb bewährter Systeme und der langfristig unvermeidlichen Erneuerung gestaltet – ohne das laufende Geschäft zu gefährden und ohne in Aktionismus zu verfallen. Eine tragfähige Strategie kombiniert in aller Regel kurzfristige Wissenssicherung, mittelfristige Modernisierung der Ränder und eine langfristige, gut vorbereitete Perspektive für den Kern.
Berührt werden dabei häufig auch rechtliche und regulatorische Aspekte, gerade in Bank-, Versicherungs- und Verwaltungsumfeldern: Aufbewahrungspflichten, regulatorische Anforderungen an geschäftskritische Systeme, Lizenzbedingungen der eingesetzten Compiler und Produkte sowie vertragliche Bindungen. Diese Punkte sind im Einzelfall sorgfältig zu prüfen. Die Ausführungen in diesem Artikel sind eine allgemeine fachliche Einordnung aus IT- und Projektsicht und keine Rechtsberatung; die konkrete rechtliche Bewertung gehört in die Hände fachkundiger rechtlicher Begleitung.
