Thought Leadership: Lessons Learned While Building the Assembler Bootcamp

By Michael Stack

Editor’s note – Looking for expert training in Assembler? SHARE is pleased to announce the launch of SHARE Academy: Assembler Bootcamp, which will be held Feb. 28, 2016, at SHARE in San Antonio. Registration will open soon! Be sure to visit the SHARE in San Antonio Web page as new information will be released soon.

This story begins with a suggestion from IBM’s John Ehrman at the summer SHARE meeting in 2000. John “owned” the High-Level Assembler program (HLASM) at IBM, and he was always looking for ways to share his knowledge and enjoyment of assembler language with others.

“What we need,” he told me, “is an assembler language bootcamp.”

“I can do that,” I said, too quickly. I was teaching Assembler Language at Northern Illinois University (NIU), and I felt comfortable with the idea of extracting one-hour SHARE presentations from a semester’s worth of lectures and exams. Talk about overconfidence...

Among programming languages, assembler is unique in requiring the programmer to learn two languages: the assembler programming language itself and the machine language of the computer (e.g., z System) the assembled program runs on. This creates confusion in the minds of some students and makes the language somewhat more difficult to teach. In addition, there are concepts in assembler which do not exist in other languages; for example, the USING instruction and data accesses by memory address. These concepts are very difficult for beginners.

John and I decided that the intended audience would include: people managing assembler programmers, other language programmers who had been assigned to maintain z System exits in assembler and anyone who wanted to have a very basic understanding of assembler programming. In a word: beginners (to assembler).

So, during the next year I worked on creating the Assembler Bootcamp (ABC) for presentation at the summer 2001 event, SHARE in Minneapolis. At first, I had no idea which topics to present and how many sessions would be required. Attendees would have no textbook, so I decided to include only material I had originally written for the NIU course. John also produced some programming laboratory material that was invaluable in increasing attendees’ comprehension.

Teaching NIU computer science courses taught me a lot about how best to present the material. I also learned, as most teachers do, to recognize when students are failing to comprehend. The best way to improve programming comprehension is to write programs, and assembler students at NIU had at least 10 to write during a semester. We couldn’t do that in the ABC, of course, but John’s lab material provided attendees the opportunity to copy and run a simple program. Most attendees found that very satisfying, so much so that I wouldn’t consider presenting the ABC without those lab sessions.

Having thought about how to structure the ABC, I began in the spring of 2001 to create slides for Session 1 using Lotus Freelance, an alternative to PowerPoint. The first session differed from the others in that it did not cover assembler language instructions. Instead, it focused on the following: conversion among decimal, binary and hexadecimal; arithmetic in those number systems; main storage organization (words, double words, addresses, etc.); and integer arithmetic and overflow.

The remaining presentations were the “meat” of the ABC in that they described instructions and coding practices. Once I started writing these presentations, I was faced with what was probably the most important decision in the creation process: which instructions to include.

During the past half century, the progression from System/360 to z System has increased the number of instructions and architecture features many times over. For professional assembler programmers, this means ongoing education. For beginners, though, and with a limited number of sessions, there is little to be gained by including any instructions beyond those in System/360.

This may seem to some to be an unnecessary limitation, but experience shows that it is not. In fact, NIU’s current full semester assembler course doesn’t go beyond a few System/370 instructions, as there is no didactic advantage.

The result was that following outlines for Sessions 2-5:

  • Session 2: AR, SR, LR, L, ST, A and S.
  • Session 3: USING, CR, C, BCR and BC.
  • Session 4: EQU, LTORG, LA, BCTR, BCT, BALR, BAL, STM, LM, DC, MR, M, DR and D.
  • Session 5: MVI, CLI, MVC, CLC, DS, PACK, UNPK, CVB, CVD, AP, CP, DP, MP, SRP, SP, ZAP, TM and 12 logical instructions.

Those reading carefully will note that a 370 instruction, SRP, is mentioned. Also, the decimal instructions add, compare, multiply, etc., were only mentioned and not discussed.

Each session covered architecture and programming characteristics as well as instructions. And even for readers with no knowledge of assembler, it should be clear that each session covered an increasing amount of material.

I presented the ABC a dozen times after the summer of 2001, and the evaluations from each session were mostly positive. I’m grateful to John for previewing each presentation and providing corrections and suggestions for improvement.

If there are lessons here, I’d say they are:

  • Teach the material to beginners before you create a bootcamp;
  • Follow the KISS rule — keep it simple, stupid — when structuring the sessions; and
  • Choose fewer topics and discuss them well.

That first rule may be difficult to follow, but perhaps your employer will allow you to “experiment” on co-workers who would like to learn something about the topic.

Whatever you do, teach something you enjoy!

Michael Stack was the manager of systems programming and an instructor in computer science at Northern Illinois University. He began teaching a graduate course in applied systems programming in 1984. He also taught assembler language programming and data structures in assembler for many years. He began volunteering with SHARE in 1975, and he finally got around to retiring in 2008.

Recent Stories
Blockchain through the Prism of Pervasive Encryption: Part I

Blockchain Is Changing the World

Demystifying the Disruption Known as Blockchain