patchingobjectdeck
| Field | Computer Programming |
| Went Obsolete | Early 80s? |
| Made Obsolete By | Fast assemblers for assembler language programs |
| Knowledge Assumed | Assembler language, machine language |
| When useful | Anytime you find a keypunch machine, a reader, and an object deck, and want to change the program, but don't have an assembler program |
Long ago, when the world was young, IBM 360 assembler language programmers knew where all the bits in the machine were. They wrote programs in assembler language, which had a one-to-one, instruction-by-instruction correspondence with machine language. These program instructions (the “program source code deck”) were punched into cards, one instruction per card, and put into a card reader. An assembler program read the cards and created machine language instructions, for example, add the contents of register one to whatever number is sitting in the address that register six points to, and put the answer in the address that register nine points to.
These instructions were encoded and then punched out on cards, many instructions per card. The resulting thin pile of cards was called an “object deck.” The programmer could take the object deck and some data, add some “job control language” (JCL), and feed it back into the machine, which would use the encoded “object deck” to read and manipulate the data.
A big program could take 45 minutes to “assemble” into an object deck. Once the program was working, you could use the same object deck over and over with different data, without having to re-assemble the program each time.
If you made a mistake and wanted to change the program, you had to fix the program source code deck, feed it into the stack of jobs waiting for the computer's attention, wait, get the object deck back, fix it up with data and job control language, and stick it back into the computer's job stack, and wait to see if the job worked.
If you just had a minor change to make, and you how object decks were encoded, you could find the place in the object deck where the bad instruction was, and duplicate the card that contained that bad instruction, stopping when you got to the bad instruction and typing in the binary code for the instruction you hoped would work. Then you'd duplicate the rest of the card.
This skipped the program assembly step, which could be several hours in a busy data processing center. And it would impress your co-workers.
