Building Systems

IBM’s engineers built an entire industry around the processing cards and the “Unit Record” machines built to process them. How they managed to use these cards to store data, and ultimately, create information directly influences many aspects of how we use computers today. This is no truer than our concept of “database”.

It’s the organization of punched cards into decks that influences how we conceptualize database “tables”. Sorting and collating cards using common data punches into specific card columns allows cards (and thus “information”) to be related. These fields become the familiar primary and foreign keys we use in relational databases. The concept of “normalization” was just important in the early punched card days as it is today. If you don’t have the right punches in the right places on the right cards, your punched card system fails the same way a SQL database is unworkable today.

A Punch Card Application

It’s 1932, Herbert Hoover is President, Jack Benny has his first radio show on the Blue Network, and you’ve been tasked with building an accounting system for your employer. How do you do this with a few simple machines? It’s surprisingly simple.

Card Design 1 – The Customer Master Card

Let’s begin with creating a Master Customer card deck. We will use a customer number to identify each customer. Let’s say we expect no more than 999 customers. This means that we can assign customer numbers 001 through 999 in columns 1,2, and 3. We’ll need a customer name and address. let’s assume that we can use columns 4 through 72 for this. We’ll use columns 73-80 for the current balance ($99,999.99 is the maximum value we can punch).

We then have someone from accounting prepare their old paper records and have them transcribed onto punched cards. If we have 500 customers, we’ll end up with a deck of 500 cards.

(The year 1933 was chosen on purpose for this example as this was the year the IBM 032 keypunch was introduced. This was IBM’s first aphanumeric keypunch.)

Card Design 2 – The Payment Transaction Card

Next, we define a new card layout for keeping track of payments. We’ll use columns 1-3 as the customer number. (Note that I’m being smart here. I’m using the same columns as the customer master record.)

We can use columns 4-13 for the date, and 14-19 for the payment amount.

We’ll use a ‘1’ punched in column 20 to indicate that this is a Payment Transaction card. (This will be used later to control whether we subtract or add transaction amounts from the totals.)

Card Design 3 – The Purchase Transaction Card

We also need to define a new card layout for keeping track of purchases.

  • We’ll use columns 1-3 again as the customer number.
  • We will use columns 5-13 again for the date and 14-19 for the purchase amount.
  • We’ll punch a ‘2’ punched in column 20 to indicate that this is a Purchase Transaction card.
  • We will use columns 21-80 for a description of what was purchased.

We then have someone in the Accounting Department record the payments and purchases for the month onto punched cards. If we expect an average of 10 transactions per customer, we might get a deck of 10,000 cards. Once this is done, we’re ready to run our month-end accounting.

Application Flow

Step 1 – Sorting

We start by sorting the Customer Master cards first. (Usually, these were called “decks”.) We put these through our card sorter, sorting first on column 3, then 2, and finally 1. We now have the deck sorted by customer number.

Sort time: 3 passes x 1,000 cards = 3,000 cards = 3 minutes @ 1,000/min

We then collect all our payment and purchase transaction cards together and sort by columns 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, and 1. We now have a card deck sorted by customer number and date. (I’m assuming a more modern yyyymmdd date format. Although it’s 1932, we don’t want any Y2K problems. Other formats require changing the order of the columns selected when doing each pass on the card sorter.)

Sort time: 13 passes x 10,000 cards = 133,000 cards = 133 minutes @ 1,000/min

Total Sort time: 136 minutes

Step 2- Collating

Now we need to interleave the transaction cards with their corresponding customer master cards. For this, we’ll use a collator. We put the sorted customer master deck into the first hopper (#1), and the transaction deck into hopper #2. We set up a plug board to compare columns 1-3 on the cards in the hopper #1 with columns 1-3 of the hopper #2. The machine is programmed to stage a card form the hopper #1 and pass it under the read brushes. We might as well immediately eject it into the first pocket (we’ll use only the first output pocket for this run). The machine maintains switches for all 80 columns of the card from hopper #1 so that we can compare values against cards read from the hopper #2.

Here’s the tricky part. We might not have any transactions for some customers. So, the card in hopper #2 might not match the card just read in hopper #2. If it doesn’t, we have to reading the cards from hopper #1, skipping forwards until we find the matching customer card. Once there’s a match, we can wire the machine to eject the card in hopper #2 into the hopper. We have the machine read the next card in hopper #2 and start over.

With this simple process, we’ll end up with a merged deck of cards in the correct order with the cards sorted by customer number in columns 1-3 and the transactions sorted by date in columns 5-13.

(Of course, if the initial sort was not done properly, or someone accidently shuffled the card decks, this process would not work. The people doing this work were highly trained.)

Total time: 13,000 cards = 62 minutes @ 250 cards/min

Step 3 – Tabulating

Now we are ready to put the collated deck of cards into the tabulator.

We set up the tabulator to read the first card from the deck. The ‘0’ in the 4th column indicates that this is a new customer. We’ll wire the machine plug board to use the data in columns 5-72 to print the customer’s name and address. We reset the accumulator and set its value to the punches in columns 73-80. That’s our balance forward which we’ll print as the balance forward.

Now we read the next card. If it’s the same customer number as the first, we look at the 4th column to determine if we need to add or subtract the number found in columns 15-20 from the accumulator. A ‘1’ indicates a payment, so we subtract; ‘2’ indicates a purchase, so we add the value. We print the date, transaction amount, and remainder of the card on the printer and repeat the process, reading the next card.

We keep reading more cards until the customer number in columns 1-3 changes. Before we do anything else, we tell the machine to print the value of the accumulator (the tabulator) onto the paper. This is the final balance which we print. We then give the printer a command to skip to the top of the next sheet of paper. (These are continuous forms with pin-feeds on the side.)

Our last step is to punch a new customer master card. We wire the plugboard to copy columns 1-72 of the original customer card to columns 1-72 on the card punch. We wire the accumulator to columns 73-80 of the card punch. The card is punched and we have the first card of the customer master deck to be used for next month’s accounting cycle.

This simple 3-step process keeps repeating itself until we run out of cards. We keep the new card deck. We’ll want to save the old cards for reporting purposes (more sorting, collating, and printing), but we could throw them away at this stage. We have a brand new customer master card deck with up-to-date balances.

Total time: 13,000 cards = 62 minutes @ 250 cards/min


The 3-step system described above, although laborious and prone to errors, it was surprisingly fast. By my calculations, the above could be accomplished in 260 minutes. (You can see why IBM’s card sorters had to be so fast. Sorting took up about half the total time.)

The above scenario is admittedly over simplified. Accountants like to track of “aged” balances. They might want to set credit limits. I’ve ignored adjusting transactions such as returns and interest. Sales might want to keep track of transactions by store and salesman. We might also want to keep track of customer history, perhaps a maintaining total of each month’s transactions and balances.

With a few more steps, and a few more punches, this can be easily accomplished. I may have to have 2 or 3 cards per customer; I may have to do some more sorting; I may have to extract sales data and punch new cards. The point is, it’s not difficult at all.