An article by Uwe Graf, Head of Consulting at EasiRun.
Although it has been a while since I ran an HLASM workshop for a partner, some of the experiences from it have stayed remarkably fresh in my mind. That is probably because the workshop confirmed much of what has bothered me about traditional teaching methods for a long time: people do not learn a technology by being confronted with as many slides, instructions, and definitions as possible in the shortest possible time.
The group of participants could hardly have been more diverse. It ranged from complete newcomers to developers who had programmed in assembler years ago and now wanted to renew their acquaintance with registers, addresses, and condition codes. For some, the journey began with the question of what exactly a register does. For others, it was more about finding out whether what they remembered still applied or had since acquired little more than nostalgic value.
Expectations for the workshop were equally varied. Some participants were primarily interested in assembler as the bridge between software and hardware. Others wanted to understand how HLASM programs interact with the Language Environment. There were also questions about instructions, addressing in 31-bit and 64-bit addressing modes, and assembler programming in an IMS environment.
And then there was the almost philosophical question of whether structured programming is actually possible in assembler. The short answer is: yes, it is. But you have to make a conscious effort to do it and occasionally resist the understandable urge to solve every problem with yet another branch instruction.
With such a mix of backgrounds and interests, it quickly became clear that a traditional, linear training course would not be enough. After all, HLASM is not a vocabulary test with particularly cryptic terminology. Someone who simply memorizes opcodes and syntax may know a few instructions afterwards, but that does not mean they understand what is actually happening in the system.
What matters are the connections. How is data addressed? What is in which register at any given point in time? What role does the Language Environment play? How do the application, runtime environment, operating system, and subsystems interact? What assumptions does existing code rely on? And why does the computer ultimately do exactly what the program tells it to do, but not necessarily what the developer intended?
For me, the key was therefore enablement. By that, I mean more than teaching features, syntax, or product capabilities. It is about equipping people to understand, evaluate, and apply a technology within their actual working environment. That may sound obvious, but in practice it is surprisingly often underestimated.
In the context of the workshop, this meant not treating HLASM as an isolated collection of instructions. The individual topics should not stand alongside one another without any connection; they should come together to form a coherent picture. A beginner first needs a solid understanding of how an assembler program fundamentally works. An experienced developer may need less of the basics, but more context around today’s runtime and operating environments. Someone looking at HLASM from an architectural perspective, meanwhile, is interested not only in individual instructions but also in interfaces, data flows, dependencies, and responsibilities.
My job, therefore, was not simply to answer the question of what the participants should know about HLASM. Equally important was the question of what they should be able to do better after the workshop. They should be better equipped to assess existing programs, understand the reasoning behind technical decisions, and identify potential risks earlier. Above all, they should have enough orientation to continue working independently afterwards.
Of course, that did not mean syntax or knowledge of instructions was unimportant. With assembler in particular, linguistic precision pays off, because computers have very little appreciation for creative interpretation. But this knowledge only becomes truly valuable when it is combined with an understanding of the underlying architecture and the specific context in which the technology is being used.
So my goal really was enablement rather than information overload. I wanted to build on different levels of prior knowledge, make the connections visible, and create room for the questions arising from the participants’ day-to-day work. After all, a workshop is not successful simply because the final slide was shown without incident. It is successful when participants can approach a real problem with greater confidence the next working day.
This idea becomes particularly important in the context of modernization. Modernization initiatives often shift very quickly toward discussing the desired target technology. The conversation turns to Java, cloud, APIs, microservices, Kubernetes, test automation, or AI-assisted development. All of these technologies can be valuable. But they do not automatically answer the crucial question of what an existing system actually does and which business and technical dependencies have evolved within it over years or even decades.
Anyone who wants to modify, extend, or ultimately replace an HLASM-based system first needs to understand which processes must be preserved, which data structures are critical, and which interfaces are genuinely stable. Equally important is knowing which operational requirements still need to be met and which changes can safely be made without putting the system as a whole at risk.
A new technology stack is not a modernization strategy. At best, it is one component of one. An unknown dependency does not disappear simply because you give it a more modern name and place it in a new architecture diagram.
Modernization rarely fails because no modern technology is available. It fails more often because the existing reality was not understood well enough, or because the teams involved were not enabled early enough to deal with the new reality. That is precisely why an HLASM workshop can also be valuable as part of a modernization initiative. It helps preserve existing knowledge, make dependencies and relationships visible, and support better-informed decisions about the future of a system.
This principle does not apply only to older technologies. A modern technology does not automatically become manageable simply because it comes with a more attractive user interface or a more contemporary architectural model. Whether we are talking about HLASM, COBOL, Java, Python, cloud services, containers, or CI/CD pipelines, teams need to be able to judge when a technology genuinely solves a problem and when it merely creates a new problem in more modern packaging. This is not simply a question of training; it is a question of capability.
Naturally, I also wanted the workshop to address how artificial intelligence can support assembler programmers, using IBM Bob as an example. The possibilities are particularly interesting for a language such as HLASM. AI-assisted tools can explain existing code, support analysis, generate documentation, suggest testing ideas, or propose initial approaches to solving a problem.
That creates significant opportunities. At the same time, it introduces a new kind of risk, because the output of these tools often sounds plausible without necessarily being correct. And in complex IT environments, plausibility is simply not enough.
AI-generated code is not the same as reviewed code. Automatically generated documentation is not the same as verified system knowledge. A suggested test case is no substitute for a test strategy. And a convincingly worded answer to an architectural question is a long way from being a sound architectural decision.
AI, too, can explain with great confidence why an incorrect branch supposedly leads to exactly the right place. Nicely worded nonsense is still nonsense, even when the syntax looks impressive.
AI can significantly increase productivity when developers know how to handle its output. They need to ask good questions, validate answers from both a technical and domain perspective, and recognize existing dependencies. Above all, they need to be able to decide when a suggestion is useful and when it could become dangerous.
This means that AI is not a substitute for enablement. On the contrary, it makes the case for enablement even stronger. The more tools explain, generate, and automate, the more important the human ability to evaluate their output and place it in the right context becomes.
The workshop reminded me once again that HLASM training does not have to be dry or backward-looking. In fact, it is precisely the combination of a solid technical foundation, architectural context, different levels of experience, and modern tools that makes the subject come alive.
I thoroughly enjoyed the workshop. I hope the participants felt the same way and came away with more than just a collection of individual instructions or syntax rules. Ideally, they also gained greater confidence in understanding existing systems, assessing technical decisions, and using new tools responsibly.
Because that is ultimately what enablement is about: after a workshop, participants should not simply have heard more. They should be able to do more.