The importance of context

I am about to display my programming roots. History alert.
In a far off kingdom computers were made by an all powerful company - called IBM. IBM had the most magnificent Operating System, inventively called "OS". This operating system came in a number of dialects (OS/MFT, OS/MVT - eventually morphing to SVS and MVS before becoming Z/OS). The people marveled. What wondrous naming! But I digress.
To get work done on these behemoths - especially batch work, a special dialect, conjured from an unfettered imagination, was created. This dialect - whose name is uttered in hushed tones was "JCL" or "Job Control Language".
JCL provided the context under which jobs are scheduled, programs executed, files were created or disposed (disposition processing). The JCL sorcerers were much in demand in the early devops days.
IBM provided a series of utilities for doing useful tasks to files, jobs, etc. But the most cunning, the most fiendish of all was the well named IEFBR14. Befor describing its inner workings in gory detail, we need to step back and look at the JCL some more.
When a program executes in an "OS" environment, it can indicate to the environment that it has been successful or has failed. This is done using a "Return Code". Nothing strange there - at least not on the surface. However the return code value can be used to control what happens next. For example if a program is supposed to create a file, but somehow aborts, one can through the magic of JCL say that the system is to delete the file. If the program is successful, one could tell the system that the file is to be kept, etc.
Genius.
So where was this return code kept? In a general pirpose "register" called register15 (R15) for short. Why there? Because R15 had a use at the beginning of the program and not much thereafter. When a program executes, R15 contains the memory address of the entry point of the program (well almost, but that's close enough for government work). So the one value one would not expect in R15 was 0. It was thus important to explicitly set R15 to the proper value before the program terminated. Other wise the return code would be the starting address of the program. Awkward.
Now lets look at the program IEFBR14. It's genius was that it did absolutely nothing. It started and immediately exited. It used to consist of a single machine instruction. The instruction (BR 14) that causes the program to terminate (actually branch to the address held in register 14, which by convention at the end of the program is back to the OS). When the program terminates, disposition - as controlled by JCL takes over. Since the return code value was random and arbitrary (except its value is always nonzero and evenly divisible by 4), no exection of IEFBR14 ever executed cleanly. Thus messing up disposition processing.
To end a long story, the size of the program IEFBR14 was doubled. From one instruction to 2. First off R15 was cleared to zero - at least its value is now predictable. And then the BR14 instruction executes. Victory!
The important lesson, however, is that you cannot ignore the context in which your systems (in this case a simple program) execute. The environmentals are key.