Hollerith Punch Card
Hollerith Punch CardPunched cards are an old input (sometimes output) medium for communicating with mainframes. Bits were represented by punching holes in the right places, the job performed by a keypunch machine which had an alpha keyboard.
Analogously, data are recorded on a DVD by stamping or burning much smaller holes. Engineering-wise, the mechanism is mechanical, like a player piano.
In FortranLanguage, the format code for text is H, which stands for Hollerith.
Hollerith was inspired by the punched cards used to program Jacquard looms.
History:
This is the reason old programmers asked to be buried "face down, 9-edge leading" :-) -- PaulMorrison
These cards could be punched by the computer (for example to dump the contents of a file) or by the user (for example to prepare input for the computer - programs and data).
In those days, the programmer usually wrote the program on sheets of paper from a "coding pad", and a "keypunch operator" typed it on the card punching machine. A second keypunch operator typed the same text again, to produce a second card deck. The two decks were fed into a special card reader called a "verifier" that would check that the cards in the two decks were identical, thereby flagging any keypunch errors.
[Well, not quite, as I recall. -- The verifier was much like a second card punch machine (or perhaps even an alternate operation mode of the first?) where an operator loaded a punched deck where the new cards would typically go, and re-keyed from the same original coding sheet. Instead of punching new holes, the verifier would just detect differences between what was in the deck being checked and what was being re-keyed. (I also seem to recall the verifier would lock up when an error was detected at which time the original card would be duped up to the offending column where the correction would be made.)] -- JimRussell
Note that since the punched cards were the digital information, these peripheral devices for punching, verifying etc were often standalone machines not connected to the mainframe itself, and in fact sometimes not even in the same building. But of course the mainframe needed to have a card reader, so that the program and its data could be input for an execution run, and a card punch for output data.
A program to be executed typically consisted of control cards, program cards, and data cards. The control cards used some column-sensitive arcane language such as JCL (JobControlLanguage) to specify which executable to run (for instance a fortran compiler), how much core and disk to allocate at the beginning of the run, which account number to charge, etc. This was followed by e.g. the Fortran program, followed by an end-of-program card, followed by data cards, followed by an end-of-run card.
Punched cards had their heyday in the 1960s and 1970s, with display terminals fairly widely replacing them by the late 1970s, although the technology is around 100 years old and was used in pre-computer applications such as census tallying.
They originated as a means of controlling the Jacquard automated weaving loom circa 1840.
For the curious: punched cards and PaperTape share a set of technologies. First, one has to make the holes. There are a variety of ways to do this. Generally an electro-mechanical gadget with a traction wheel, guide grooves, guide teeth, and sharp punches with solenoids and retraction springs was used.
The readers are even more varied than the punches. A "trap" type of reader was used for one-off cards (common with crypto gear of the era) where little spring-loaded pins were pressed against the card surface from one side, and a plate with a grid of complementary contacts waited on the other side for those pins that found holes. This method read the whole card as a grid at once.
Another popular reader was the "finger feeler relay" type, where a short, lightly-sprung feeler "finger" passed over the card or tape (well, actually the card/tape passed over the fingers) and at those points where a hole was, the "finger" dropped through and a relay at the back of that lever arm closed. This method read rows of holes at a time and required some sort of clocked movement to assure clean reads. This was the most common type used in PaperTape readers.
Later developments were optical readers (much faster than the mechanical ones) and forced air readers (and I've only ever seen one of those). I'm sure there were other kinds of readers, but it's been more than two decades since I used this stuff.
When I was a kid, some volunteers came from the big city out to our hick town to give intro classes about computers after school using scrounged equipment and a desktop programmable calculator. Almost immediately they lost use of the portable card punch, and we had to punch the cards by hand using a paper clip!
And then, although cards were cheap, nonetheless they were such a pain to punch this way that they had us fix errors by taping over holes, when possible. Gradually some students got some very simple programs to work.
Then the volunteers lost use of the card reader. They scrounged around and finally got the loan of a nice shiny new one. An optical reader. And we had patched our programs using transparent scotch tape!
Long delay while everyone repunched all of their cards with a paper clip...
I swear this is a true story. It's a wonder I actually went on to become a programmer; it was pretty discouraging. And at that tender age of 13 I was still kind of confused about '=' in assignment versus in algebra.
My hick town got a card punch and a lifetime supply of cards, but no reader. This was around 1984. The powers-that-be should have told the donors to dispose of their own junk without dumping it on us. I guess it got them a tax deduction.
Quick test to see if you really remember working with tab cards:
What is the order of the rows, from top to bottom?
What is a "sign overpunch"?
Could you still prepare a card for the program drum on a keypunch?
Drum cards! Drum cards! That's like being able to take a cube root by hand! Actually not. When I was first programming at the "computer center", I knew how to make drum cards and it really sped up my work, especially for FORTRAN. Also, if one was living the graduate student life style, and had a hole on one's shoe, the cards where great for putting into your shoe because they were such high quality and tough paper. They had the highest value of any paper for recycling, also.
When I used these cards for programs, the output decks did not have anything written on them. This was a problem if 2000 card program deck was dropped on the floor. The solution was to draw a diagonal line across the top of the new deck using a felt tipped pen. This gave a means of ordering the cards if they became out of order. Often, this was the program, i.e. there was no copy on disk. Also, and for long afterwards, I did not have a tool for comparing two programs. It had to be done by hand, spreading the two listings out on a table.
The most tricky cards to get right were the command cards for IBM JCL (JobControlLanguage) for the IBM 360 and 370 computers. (Ever guessed at the ratio of JCL cards that were punched(new) vs. duped(copied). My guess is each new one (that worked) was probably copied at least 50 times.)
I once had a job fail because the job after mine was put onto the card reader BACK TO FRONT and became data added to my job.
The days of Hollerith cards were the days when computer time was very expensive. So one would prefer not to burden the computer with something as straightforward as a simple sort, if one had an IBM card sorter. The card sorter physically shuffled the cards into order because this was cheaper than having the computer sort the records into order.
The computer was unlikely to be able to hold all records in memory ("core") or even on disk at the same time, so a physical card sort saved multiple "merge sort" passes (each of which would have to be written to magnetic tape which would then be rewound prior to the next pass).
256MB on a personal computer? It was only four decades ago that all the memory in the world didn't add up to 256MB.
Originally punched cards were used mostly for purely numeric data, often in BCD (Binary Coded Decimal), which makes perfect sense. IBM extended BCD to add alphabetic and punctuation characters in a way that was backward compatible with BCD; the result was EBCDIC (Extended Binary Coded Decimal Interchange Code).
Knowing BCD encoding thus assisted as a base in understanding or memorizing the other EBCDIC codes.
As you can see from the picture at the top, cards naturally supported numbers (one column per numeric position). BCD comes in when you have to support numbers on a bit-oriented machine (they were not always so - the 650 used what was called biquinary coding - you can guess what that means!). When IBM needed to add support for alpha characters, they used the two overpunch rows (11 and 12, which also did duty as signs) - these later came to relate to the first 2 bits in an EBCDIC byte, e.g. 'A' is X'C1', which is 12-1. They used the 0 row for the S-Z range. 'S' is 0-2 (X'E2' in EBCDIC) because they didn't want 0 and 1 punches in the same column. Some special characters even used 3 punches in a column, but putting too many holes in a card could seriously weaken it....
No kidding. Some folks would always get a bright idea to try to compress as much data onto one card as possible, since smaller stacks of cards are of course easier to manage. Such overpunched cards were known as "lace cards", and had a real tendency to jam, shred, and completely gum up the works.
See: PaperTape for more discussion of punch tapes, punch cards, the origin of the DEL character, encoding, and how the encoding is related to medium integrity.
Just came across this nice little mnemonic, taught in the US Navy DP school for memorizing the punch-card Hollerith codes for the alphabet::
A J Squared Away
Actually, for the coding (see US Navy mnemonic "AJ Squared away" above), S-Z were numerics 2-9 with zone 10. Why not 1 instead of 2? Because the two rows were so close that early machines had problems discriminating which rows were punched.
On Keypunches & verifiers: 026, 029, and 129 were all keypunches, I believe. The higher numbered models were newer, and had keyboard buffering where punching was not done immediately within a given field (using the program drum, of course) until you "tabbed" or "field exited" to the next field. I seem to recall that the verifer was model 056. Already punched cards placed into the hopper, and the user re-typed the original data, while the machine compared keystokes to actual punches. If no errors were found, a notch was punched in the right edge of the card. If a mismatch was found, the operator was given 3 tries to get the data correct (maybe it was the verifer who had miskeyed), and on the third unsuccessful try, a notch was punched above the column in error on the top edge of the card.
Not discussed so far is mark-sensing. Using the #2 lead pencil, some columns could be marked with pencil (three "punch-hole columns were needed for each mark-sense column. The cards were then placed in a "Reproducer" which could read the marks, and punch the corresponding "marked" data onto the same card, even in a different area of the card, or on an entirely new card.
Cards were also used in electro-mechanical accounting machines (401, 402, etc), rather than electronic computers, where they could easily perform tasks such as invoices and statements. No equations other than add/subtract and compare. These machines were not cheap, but still not expensive as real computers.
The cards were OK, but the chaff was to die for! (Yeah, the sharp corners were a pain, but what a mess you could make!) -- BobBockholt
Actually, recycled cards from the computer centre proved very handy for writing revision notes on (flash cards) - thus starting my 5 by 3 card habit. The wide line printer paper could be had in four inch thick piles as well - I used the stuff for rough calculations for years. Late 1970s in a UK University.... -- KeithBurnett
Did a punch card ever have 'hanging chads' that changed the result of the calculation? (sorry, couldn't resist)
Holler and Punch
I came in on the tail end of the card era for some intern work and don't miss cards one bit (bad pun). The card-punch machine I was using once punched the holes about 2 millimeters off the "proper" position. It was at the threshold for the reader and thus the reader refused to read some of the cards in the deck. I would re-punch (copy) those identified as bad cards and try again.
But the next time through, a different set of cards were rejected. After about the 4th cycle of this, a "seasoned" mainframer came to help because the deadline was looming and there was no time to find the tapes to create a fresh set of cards. He pulled out what looked like a jewelry eye-scope, aligned it against a template card he had, and held it up to the light. After examining it for about a 2 minutes, he explained the problem and told our group to find a different punch machine to make a new batch of cards using either the bad deck or ideally the original tape(s), if found.
Those seasoned people had all kinds of tools in their bag. They sometimes poured iron powder over a thin sheet of paper placed over a flattened section of reel-to-reel tape to study wear patterns and alignment of the magnetic data patterns. The pattern looked like tire treads. Sometimes the tapes had a similar intermittent pattern of problems to the cards.
Now adays we just make a fresh copy and toss the bad tape/disk/media-thing. But back then tapes were expensive and card copies were not always easy to make, especially if they came from multiple different sources. Plus, the data patterns imprinted on the medium these days are too small for the human eye now.
EditText of this page
(last edited October 23, 2013)
or FindPage with title or text search