This set of examples takes you through a typical data processing sequence for a company. The card deck "master1.pcd" contains a set of customer "master" cards, each containing static information about a customer along with that customer's current balance. Credit balances are indicated by an "X" punch ('-' character) in column 40. These cards are kept in sorted order by customer ID, as a convenience. The file "detail1.pcd" contains customer transactions (e.g. purchases and payments). Payments are indicated by an "X" punch ('-' character) in column 40. These cards are not sorted, as they typically would come straight from data entry where they were punched from paper invoices - which were likely processed in chronological order, plus possibly punched by several different operators and then arbitrarely combined.
In order to process a month's transactions, first the detail cards need to be sorted by customer ID (using the sorter). Then, the detail cards and master cards need to be merged such that each customer card is followed by their transaction cards (using the collator). Finally, this combined deck of master-detail cards is passed through the accounting machine to produce a report and also to punch new customer master cards with updated balances (on the summary punch). These new customer master cards become the input for the next month's processing. The original master and details cards might be archived, but are otherwise not normally used again.
Columns | Contents |
---|---|
1-4 | Customer ID (numeric) |
5-19 | First name (alphabetic) |
20-34 | Last name (alphabetic) |
35-39 | Zip code (numeric) |
40 | "X" punch ('-') for credit |
41-48 | Balance (numeric, 2 decimal positions) |
The transaction (detail) cards ("detail1") contain the following data:
Columns | Contents |
---|---|
1-4 | Customer ID (numeric) |
40 | "X" punch ('-') for payments (credits) |
41-48 | Transaction Amount (numeric, 2 implied decimal positions) |
This step demonstrates the data entry phase. Since the output of this step is the card deck "detail1", which already exists, it is not strictly necessary.
The amounts must be entered as right-justified, zero-filled, 8-digit values with an assumed decimal point at 2 places. Since data entry input documents are typically prepared by humans, and even hand-written, an data entry operator must be able to glance at the value and know how many leading zeros (or blanks) to type. Experienced keypunch operators could very quickly predict how many zeros to punch.
Most good keypuch operators would never look at the card being punched (let alone the keyboard). Even with the best keypunchers, mistakes would happen. Data entry often consisted of two phases - data entry and data verification. For verification, a different operator would re-enter the data on a keypunch setup to verify - where it does not punch what is typed by only compares with what was previously punched and jams when there is a mis-match. The operator would then have to examine the document, card, and their own typing to determine where the mistake was. Verification is not covered in this example.
The input data document has data grouped by customer ID, although not in numerical order. Depending on how the original data was gathered, this may or may not have been the case for a given data entry job.
Start the DataCenter application, which provides central access to all punch-card data processing equipment.
NOTE: the program drum card may be viewed by pressing Ctrl-A. This also sends the current card to the output stacker, so keep that in mind. To return to data entry, press Ctrl-A again, which feeds another card.
Start the DataCenter application, which provides central access to all punch-card data processing equipment.
NOTE: card decks may be viewed using the "Viewer" application, available in the "File" menu. Only saved files may be viewed, not the contents of hoppers or stackers.
Customer ID is in columns 1-4. Sorting must begin at column 4 and work towards column 1.
NOTE: At this point, the new balance cards in "master2" contain only the customer ID and new balance. Additional customer info must be transferred from the previous master cards ("master1").
NOTE: since we have the original "master1" file in-tact, this step is not necessary in a virtual world. But, in the old days, the master cards needed to be isolated from the detail cards in order to copy (only) their data to the new master cards. One method is to use the Collator to extract master cards into a separate pocket. An example of this method follows.
This saved deck is now ready for input to the following month's processing.