How did programming work when programmers used punchcards?

Question

I saw this: Learning to program on punchcards

and I've seen this: http://en.wikipedia.org/wiki/Computer_programming_in_the_punched_card_era

but they leave much to be desired.

Can anyone explain to me how programmers programmed when they used punchcards? Specifically, the system of input computers used to derive instructions from the punched card itself.

I do not know much about retrocomputers, so any one system of input you are familiar with would be fine. More general answers are also appreciated.

Answer 1

In a word, poorly.

At least on any machine I ever used or heard of, you did not feed cards one at a time though. There were automated card readers that would feed and read hundreds of cards a minute (probably around 1000/minute, but I'm not sure of the exact specs).

In a typical case you wrote the code by hand, then punched it onto cards. Each card holds one line of code (up to 80 columns). You took the card deck to be executed. Depending on backlog, anywhere from an hour or so to a day or so later, you got your deck back along with a printout of the results.

I should probably add: since your card deck ran as a job, you didn't just submit the code for the program itself -- you had to write something vaguely similar to a batch file/shell script with the directions to compile and execute your code. IBM JCL (for one example) remains heavily influenced by its Hollerith-card origins.

Another minor point: on most systems I remember, you normally included a line number on each punch card. You obviously avoided dropping a deck if you could, but when (not if) one got dropped, it wasn't really nearly the tragedy many imagine. Interesting side point: at least the card sorters I saw used a radix sort -- they'd separate the cards into 10 bins, based on one digit of the line number, then "merge" those together (drop all the cards into a single bin in order) then repeat as many times as you had digits in the line numbers.

Hollerith cards were extremely influential -- 80 columns as a limit still survives to an almost disturbing degree. At least on the Control Data mainframes, things like the file system were influenced quite heavily as well. Well after Hollerith cards were mostly gone, remnants of them were visible in the OS -- for example, text files were often stored as a series of 80-character records, regardless of how few/many characters a line actually contained. I can still remember my surprise at the "backwardness" of a system like Unix where you had to read all the preceding lines to find line N of a text file, instead of just being able to seek to it directly.

Answer 2

You used the card punch as an editor.

• Insert == punch a new card.
• Move == pick up the card and move it to the right spot.
• Delete == take out the card and throw it in the bin
• Copy -- better card punches had a copy function which could copy another card column by column.
• Repace a character -- use the copy function but type in the replacement characters when you reach the character you need to replace.
• Delete a character -- use the copy function but hold the copied card to stop it moving and hit space for each character you want to "delete"
• Insert characters -- use the copy function but hold the original card immobile while typing in the new text.

For the most part cards were "immutable" but you could remove characters by taping over the holes with thin opaque sticky tape.

You read in your program surrounded by the appropriate JCL and waited for the printer to spit out the results. (Could be hours!)

Answer 3

Very slowly.

My mother was such a programmer, so I had tons of these cards at home while growing up. What they would do was encoding the program on the cards, and then feeding the cards into the card reader one by one (similar to how the voting machines work now). If you dropped the cards - you would be in a lot of trouble, because you only have X machine time allocated for you and you'd have to get them arranged in the right order and restart feeding the machine all over again and try to make it on time before the next programmer kicks you out. A trivial (in our current standards) program might have required hundreds, if not thousands, of such cards, and hours of machine time to load it and run it.

Very tedious.

Answer 4

In some ways "not too different", in some ways "very different".

They wrote source code, usually on paper. This was then re-typed onto punch cards (one line of source code per card, usually with line numbers, so you could easily fix up your source code when it ended up in the wrong order).

The program was then prefixed with cards having instructions for how to compile the program and suffixed with instructions for how to run it and what data file(s) to use (or tapes to mount, etc, etc).

This as then submitted to the operators, who would load the cards into a speed-reader, run the job and return the results on print-outs.

With a typical edit/compile/results cycle being on the order of "tomorrow", people tended towards being more paranoid bench-checking their code for syntax errors.

With no possibility of interactive debugging, the only way to trace the execution would be debug lines printed during the execution.

In some places, the code would be on punch tape rather than on punch cards.