Sometimes we jokingly ask, “how hard can it be?” Don’t be complacent: even the simplest things can go wrong.

Early in my career as a software engineer, I worked on IBM System 360/370 mainframes programming customisations for the MVS operating system in assembler language.

Assembler language is not recommended for the faint of heart – it is a symbolic representation of machine code, which is only barely readable by humans but highly efficient. It deals with instructions for the computer at the lowest possible level, such as “add these two numbers”, “copy this area of memory to that”, or “jump to a new location for instructions”.

There is an operating system utility called IEFBR14, which is the trivial program. It is designed to be a stub – it literally does nothing. The original version of the program was one instruction, BR 14, branch (or jump) to the value contained in Register 14, which is the return address of the operating system scheduler module that called the program. This assembled into machine code: 07FE. It was literally the shortest program possible.

What could be simpler? What could possibly go wrong?

Unfortunately, one instruction just wasn’t enough, because programs set their return code in Register 15, with a non-zero return code indicating some sort of error. Our simplest program possible did not set a zero value in Register 15, so each time the program ran there was a random value in Register 15, which was interpreted by the operating system as a random error.

So they had to double the length of our two-byte stub to four bytes, by inserting the code XR 15,15 or 17FF at the start of the program, which zeroed Register 15 by exclusive-oring it with itself, indicating a zero return code or success, before returning to its caller.

Despite the initial thought that this program only had one job, it really had two jobs – set a successful return code, and return. Next time you think, “how hard can it be”, or say “you had one job”, or “bugger the boxing, let’s just pour the concrete”, think about little IEFBR14, the program whose name was longer than the program itself, for a lesson in preventing and remediating unanticipated side effects.

Image credit: Erik Pitti