Ein Beitrag von Uwe Graf, Head of Consulting bei EasiRun.
Auch wenn mein HLASM-Workshop für einen Partner schon eine Weile zurückliegt, sind mir einige Erfahrungen daraus sehr präsent geblieben. Das liegt vermutlich daran, dass dieser Workshop vieles von dem bestätigt hat, was mich an traditionellen Lehrmethoden schon lange stört: Menschen lernen eine Technologie nicht dadurch, dass man ihnen möglichst viele Folien, Befehle und Definitionen in möglichst kurzer Zeit zumutet.
Die Teilnehmergruppe hätte unterschiedlicher kaum sein können. Sie reichte von absoluten Newbies bis zu Entwicklern, die bereits vor längerer Zeit Assembler programmiert hatten und nun alte Bekanntschaften mit Registern, Adressen und Condition Codes auffrischen wollten. Bei den einen begann die Reise mit der Frage, was ein Register eigentlich genau macht. Bei den anderen ging es eher darum, ob das, woran sie sich erinnerten, noch immer gilt oder inzwischen nur noch nostalgischen Wert besitzt.
Ebenso vielfältig waren die Erwartungen an den Workshop. Einige Teilnehmer interessierten sich vor allem für Assembler als Brücke zwischen Software und Hardware. Andere wollten verstehen, wie HLASM-Programme mit dem Language Environment zusammenspielen. Hinzu kamen Fragen zu Befehlen, zur Adressierung im 31- und 64-Bit-Adressmodus und zur Assemblerprogrammierung im IMS-Umfeld.
Und schließlich stand noch die beinahe philosophische Frage im Raum, ob man in Assembler tatsächlich strukturiert programmieren kann. Die kurze Antwort lautet: Ja, das kann man. Man muss es allerdings bewusst tun und gelegentlich den verständlichen Impuls unterdrücken, jedes Problem mit einem weiteren Sprungbefehl lösen zu wollen.
Bei dieser Mischung aus Vorerfahrungen und Interessen war schnell klar, dass ein traditioneller, linear aufgebauter Lehrgang nicht ausreichen würde. HLASM ist schließlich kein Vokabeltest mit besonders kryptischen Begriffen. Wer lediglich Opcodes und Syntax auswendig lernt, kennt danach vielleicht einige Befehle, versteht aber noch lange nicht, was im System tatsächlich geschieht.
Entscheidend sind die Zusammenhänge. Wie werden Daten adressiert? Was befindet sich zu welchem Zeitpunkt in welchem Register? Welche Rolle spielt das Language Environment? Wie greifen Anwendung, Laufzeitumgebung, Betriebssystem und Subsysteme ineinander? Welche Annahmen liegen bestehendem Code zugrunde? Und warum macht der Rechner am Ende zwar exakt das, was im Programm steht, aber nicht unbedingt das, was der Entwickler beabsichtigt hat?
Für mich lag der Schlüssel deshalb im Enablement. Darunter verstehe ich mehr als die Vermittlung von Funktionen, Syntax oder Produktmerkmalen. Es geht darum, Menschen so zu befähigen, dass sie eine Technologie in ihrem tatsächlichen Arbeitsumfeld verstehen, bewerten und anwenden können. Das klingt zunächst selbstverständlich, wird in der Praxis aber erstaunlich häufig unterschätzt.
Auf den Workshop übertragen bedeutete das, HLASM nicht als isolierte Sammlung von Befehlen zu behandeln. Die einzelnen Themen sollten nicht unverbunden nebeneinanderstehen, sondern ein gemeinsames Bild ergeben. Ein Einsteiger benötigt zunächst ein tragfähiges Verständnis davon, wie ein Assemblerprogramm grundsätzlich arbeitet. Ein erfahrener Entwickler braucht möglicherweise weniger Grundlagen, dafür aber eine Einordnung in heutige Laufzeit- und Betriebsumgebungen. Wer aus einer Architekturperspektive auf HLASM schaut, interessiert sich wiederum nicht nur für einzelne Instruktionen, sondern ebenso für Schnittstellen, Datenflüsse, Abhängigkeiten und Verantwortlichkeiten.
Meine Aufgabe bestand deshalb nicht nur darin, die Frage zu beantworten, was die Teilnehmer über HLASM wissen sollten. Ebenso wichtig war die Frage, was sie nach dem Workshop besser können sollten. Sie sollten bestehende Programme sicherer einordnen, technische Entscheidungen besser nachvollziehen und mögliche Risiken früher erkennen können. Vor allem sollten sie genügend Orientierung erhalten, um anschließend eigenständig weiterzuarbeiten.
Das bedeutete natürlich nicht, dass Syntax oder Befehlswissen unwichtig gewesen wären. Gerade bei Assembler lohnt sich sprachliche Präzision, weil der Rechner wenig Verständnis für kreative Interpretationen zeigt. Dieses Wissen entfaltet seinen Wert aber erst dann vollständig, wenn es mit einem Verständnis für die zugrunde liegende Architektur und den konkreten Einsatzkontext verbunden wird.
Mein Ziel war daher tatsächlich Enablement statt Beschallung. Ich wollte unterschiedliche Vorkenntnisse aufgreifen, Zusammenhänge sichtbar machen und Raum für die Fragen schaffen, die sich aus der praktischen Arbeit der Teilnehmer ergaben. Ein Workshop ist schließlich nicht schon dann erfolgreich, wenn die letzte Folie ohne Zwischenfall gezeigt wurde. Er ist dann erfolgreich, wenn die Teilnehmer am nächsten Arbeitstag mit mehr Sicherheit an ein reales Problem herangehen können.
Dieser Gedanke ist gerade im Zusammenhang mit Modernisierung wichtig. Bei Modernisierungsvorhaben dreht sich die Diskussion oft sehr schnell um die gewünschte Zieltechnologie. Dann ist von Java, Cloud, APIs, Microservices, Kubernetes, Testautomatisierung oder KI-gestützter Entwicklung die Rede. Alle diese Technologien können sinnvoll sein. Sie beantworten aber nicht automatisch die entscheidende Frage, was ein bestehendes System tatsächlich leistet und welche fachlichen und technischen Abhängigkeiten darin über Jahre oder Jahrzehnte gewachsen sind.
Wer ein HLASM-basiertes System verändern, erweitern oder langfristig ablösen möchte, muss zunächst verstehen, welche Prozesse erhalten bleiben müssen, welche Datenstrukturen kritisch sind und welche Schnittstellen tatsächlich stabil sind. Ebenso wichtig ist das Wissen darüber, welche Betriebsanforderungen weiterhin erfüllt werden müssen und welche Änderungen möglich sind, ohne das Gesamtsystem zu gefährden.
Ein neuer Technologie-Stack ist noch kein Modernisierungskonzept. Er ist bestenfalls ein Bestandteil davon. Eine unbekannte Abhängigkeit verschwindet schließlich nicht dadurch, dass man ihr einen moderneren Namen gibt und sie in einem neuen Architekturdiagramm unterbringt.
Modernisierung scheitert selten daran, dass keine moderne Technologie verfügbar wäre. Sie scheitert häufiger daran, dass die bestehende Realität nicht ausreichend verstanden wurde oder dass die beteiligten Teams nicht früh genug befähigt wurden, mit der neuen Realität umzugehen. Genau deshalb kann ein HLASM-Workshop auch im Rahmen einer Modernisierung wertvoll sein. Er trägt dazu bei, vorhandenes Wissen zu sichern, Zusammenhänge sichtbar zu machen und fundiertere Entscheidungen über die Zukunft eines Systems zu treffen.
Dieser Anspruch gilt nicht nur für ältere Technologien. Auch eine moderne Technologie wird nicht automatisch beherrschbar, nur weil sie über eine attraktivere Benutzeroberfläche oder ein zeitgemäßeres Architekturmodell verfügt. Ob es um HLASM, COBOL, Java, Python, Cloud-Services, Container oder CI/CD-Pipelines geht, Teams müssen beurteilen können, wann eine Technologie tatsächlich ein Problem löst und wann sie lediglich ein neues Problem in moderner Verpackung erzeugt. Das ist keine reine Trainingsfrage, sondern eine Frage der Handlungsfähigkeit.
Natürlich wollte ich im Workshop auch die Frage aufgreifen, wie künstliche Intelligenz Assemblerprogrammierer unterstützen kann, beispielsweise am Beispiel von IBM Bob. Gerade bei einer Sprache wie HLASM sind die Möglichkeiten interessant. KI-gestützte Werkzeuge können bestehenden Code erklären, bei der Analyse helfen, Dokumentation erzeugen, Testideen vorschlagen oder erste Lösungsansätze formulieren.
Das eröffnet große Chancen. Gleichzeitig entsteht eine neue Form von Risiko, denn die Ergebnisse solcher Werkzeuge wirken häufig plausibel, ohne deshalb automatisch korrekt zu sein. Gerade in komplexen IT-Landschaften reicht Plausibilität nicht aus.
Ein KI-generierter Codevorschlag ist noch kein geprüfter Code. Eine automatisch erzeugte Dokumentation ist noch kein gesichertes Systemwissen. Ein vorgeschlagener Testfall ersetzt keine Teststrategie. Und eine überzeugend formulierte Antwort auf eine Architekturfrage ist noch lange keine tragfähige Architekturentscheidung.
Auch eine KI kann sehr selbstbewusst erklären, warum ein falscher Branch angeblich genau an die richtige Stelle führt. Freundlich formulierter Unsinn bleibt jedoch Unsinn, selbst wenn er syntaktisch beeindruckend aussieht.
KI kann die Produktivität deutlich erhöhen, wenn Entwickler wissen, wie sie mit den Ergebnissen umgehen müssen. Sie müssen gute Fragen stellen, Antworten fachlich und technisch überprüfen und bestehende Abhängigkeiten erkennen können. Vor allem müssen sie entscheiden können, wann ein Vorschlag hilfreich ist und wann er gefährlich werden könnte.
Damit wird KI nicht zum Ersatz für Enablement, sondern zu einem besonders starken Argument dafür. Je mehr Werkzeuge erklären, erzeugen und automatisieren, desto wichtiger wird die menschliche Fähigkeit, Ergebnisse zu bewerten und in den richtigen Kontext einzuordnen.
Der Workshop hat mir erneut gezeigt, dass HLASM-Training weder trocken noch rückwärtsgewandt sein muss. Gerade die Verbindung aus technischem Fundament, architektonischem Kontext, unterschiedlichen Erfahrungswelten und modernen Werkzeugen macht das Thema lebendig.
Mir hat der Workshop viel Freude gemacht. Ich hoffe, dass es den Teilnehmern ähnlich ging und dass sie nicht nur einzelne Befehle oder Syntaxregeln mitgenommen haben. Im besten Fall haben sie auch mehr Sicherheit gewonnen, um bestehende Systeme zu verstehen, technische Entscheidungen einzuordnen und neue Werkzeuge verantwortungsvoll einzusetzen.
Denn genau darum geht es beim Enablement: Die Teilnehmer sollen nach einem Workshop nicht lediglich mehr gehört haben. Sie sollen anschließend mehr können.