Talk:Unit record equipment

"Unit record equipment" category?

Some pages for various forms of unit record equipment are pointing to this page as the "main page", but, as User:R. S. Shaw noted in his removal of one such link from IBM 407, "main is used for sections, not whole article". It might be more appropriate to add a "Unit record equipment" category and have the pages currently using {{Main|Unit record equipment}} instead use [[Category:Unit record equipment]]. Guy Harris 22:07, 9 October 2006 (UTC)

Another possibility would be to use Template:SubArticle on the articles about pieces of unit record equipment if Unit record equipment gives a summary of the information in an individual article. Guy Harris 22:17, 9 October 2006 (UTC)

The Category:Unit record equipment idea clearly fits here. A category groups related articles very well. I'm in favor of putting in [[Category:Unit record equipment]] and taking out {{Main|Unit record equipment}}. I don't think Template:SubArticle would work well in this context; it's meant for talk pages, not articles, and is only used by a couple of talk pages presently. -R. S. Shaw 23:42, 9 October 2006 (UTC)

• This seemed so sensible to me, I've been bold and gone ahead and created the category. I'll be editing pages into it tonight, I suppose. I think punched card probably doesn't belong, as it is not equipment. Control panel (computer) probably does, as it is part of the equipment. -R. S. Shaw 00:21, 10 October 2006 (UTC)

• punched card does belong - they are the glue that lets the machines work together. Note that punched card is restricted to Hollerith cards, etc, it is not all punched cards. (this is not to say I agree with using a category, only that if a category is used, then .... The problem with a category is that it is not make the set of articles explict to the reader)tooold 01:23, 10 October 2006 (UTC)

UNIVAC 1005

Described on UNIVAC page as having a stored program and a programming language. If this is a unit record machine, then wouldn't the IBM 1401 also be a unit record machine? 69.106.232.37 20:45, 10 October 2006 (UTC)

I don't think so. I believe the 1005 still followed the unit record model, i.e. cards were the primary storage medium. I never used one, but my recollection was that the 1005 had very limited memory and no mass storage. It was more in the 407 class than a 1401. Here is one article i found via Google that discusses 1005 use in Vietnem: https://calldbp.leavenworth.army.mil/eng_mr/txts/VOL48/00000009/art8.pdf --agr 21:44, 10 October 2006 (UTC)

Information seems hard to come by on this and seemingly somewhat contradictory. The 1004 has a fair reference at [1], but the 1005 seems thinner. This says "the UNIVAC 1005 was a plugboard computer that you had to wire for each program" but this says "SAAL was my first real love affair: Single Address Assembler Language on a UNIVAC 1005". Supporting the latter is this: "developed a program written in IBM DOS/360 Assembly Language to automatically translate pro­grams from UNIVAC 1005 Assembly Language (SAAL) to IBM DOS/360 Assembly Language". So it does look programmable despite the first quote. Seems like a computer in a accounting-machine-like form, a close call. -R. S. Shaw 06:36, 11 October 2006 (UTC)

"Cards primary ..." would have been my definition, as well. But now I want to change my mind.

Found this site, [2], guy worked on a 1005 with about 4k memory, card read/punch, and printer. Reads just like a basic 1401.

From IBM Archives (note the "Unit Record Systems Programming"), [3], "On October 28, 1970, the company rolled out the IBM System/3 Model 6 (IBM 5406). Rochester's Advanced Unit Record Systems Programming group had developed the Report Programming Generator II programming language intended for commercial applications on the Model 6."

I think we should exclude digital computers, even if they only have card & printer capabilities, from unit record equipment. Many IBM 650 sites were card only, for example, and logically were unit record machines, but the 650 is not a machine I want to have included, no more that the 1005 or 1401. Anyone want to try writing a definition for the article? 69.106.232.37 07:05, 11 October 2006 (UTC)

The UNIVAC 1004 was plugboard-programmed but electronic, unlike the electromechanical IBM tabulators. There was an add-on for a 1004 which plugged into the plugboard area, replacing the plugboard, and made it software-programmable in a limited way. The 1005 had something like that as standard. It was close to the IBM CPC in concept, but with more electronics and fewer gears. --John Nagle (talk) 18:24, 17 September 2009 (UTC)

unclear sentence

This sentence from the 2nd paragraph needs clarification:

"The automatic operation of some unit record machines was directed by control panels, wired to directed the operation for a specific application."

1st attempt at rewrite. Ok? 69.106.232.37 23:53, 10 October 2006 (UTC)

Looks good, thanks!

How it works

This was just removed from the article by ClueBot as possible vandalism by 66.83.148.18, but I think it is fair criticism that belongs here: "but of course none of the smart people tell us how it works!!!!!!"--agr (talk) 19:46, 17 September 2009 (UTC)

I noticed that. And I agree, the article doesn't explain what one does with all those machine. I've been trying to find a reference that has a good overview of data processing with that equipment. IBM had a series titled "Punched Card Data Processing Principles"[4], but those books just introduce the various machines. --John Nagle (talk) 03:35, 18 September 2009 (UTC)

How it works, again

OK, here's a first cut at how it works.

A key concept for modern readers is to understand that none of the unit record machines have any significant amount of memory. The tabulators have the most, with 10 to 40 multi-digit counters and some "selectors" (relays) which can hold one bit of state. The sorters only read one column at a time and lack any storage devices at all. The cards are the file storage.

An invoicing/billing system might work like this:

• Transactions come in from sales reps or a sales floor, typically as paper documents to be keypunched. Each transaction is manually typed in, using a keypunch, creating a single card for each transaction, which must contain at minimum the item number, quantity, and customer number.
• Payment transactions come in from Accounts Receivable, with the customer number and payment amount.
• Transactions need to have the dollar amount for the item and the total cost computed. This requires the following steps:
  • Sort transaction cards by item number with a card sorter
  • Merge the transaction cards with a the pricing file (a deck of cards with one card for each item number, containing the price for that item) using a collator like an IBM 77. The transaction cards follow the price card for each item number. Transactions that don't match come out in the fourth output stacker of the collator, for manual attention. Note that each card must have a field with a "card type" punched, so we can separate the decks later.
  • Run the combined deck through a reproducing punch, like an IBM 514, set up for "interspersed gangpunching", so that the price per item is propagated to the following transaction cards with the same item number and punched into it. This phase also might propagate the item name (but it will have to be short; we only have 80 columns total.)
  • Run the combined deck through the collator again, or through a sorter, to separate the pricing deck from the transaction deck using the card type field. The pricing deck goes back into storage.
  • Notice that what we've just done is equivalent to an SQL "join".
  • We still don't have the total price (item price x quantity), so the transaction deck has to go through a calculating punch like an IBM 602. The multiply is done, and the product is punched back into the card that contained the operands.
  • Now all the transactions have been priced. At this point, we can run the deck (which is in order by item number at this point) through a tabulator and produce a sales report by item number, if desired.
• Now it's time to do billing. We first sort the transaction deck by customer number, and the payment transactions by customer number.
• The transaction deck is then merged with three other decks. First, the company name and address deck, which identifies the company being billed. Then, the outstanding balance deck, representing the invoice balances from the previous month. Finally, the payment deck. A typical order might be

• Name and address card 1
• Name and address card 2
• Name and address card 3
• Transaction deck
• Outstanding balance deck
• Payment deck

• These go into a printing tabulator such as a IBM 407. For this job, the IBM 514 reproducer is plugged into the tabulator for "summary punching". The summary punch will produce a new outstanding balance deck for the next billing cycle. The tabulator is loaded up with preprinted invoice forms, probably multiple-part forms with carbons, with feed holes along the edge. A "carriage tape" loop, which indicates on what print lines each invoice item should be printed is loaded into the reader on the tabulator carriage. The plugboard for the job is placed in the tabulator's plugboard rack, and the big locking handle pushed down. Then someone pushes START. The tabulator grinds away, printing the name and address from the name and address cards. The transactions are printed and added up. The outstanding balance is added. The payments are subtracted. The tabulator advances the invoice form to the line for the amount due and prints that. Then, with a loud grinding noise, the 514 starts up and punches one card, the outstanding balance for next month.
• The forms go through a decollator, which separates out the multiple copies, a burster, which separates the pages, and perhaps a folder/inserter, which puts the statements into envelopes. Then a pass through a postage meter, and they're ready for mailing.

That's automated data processing. --John Nagle (talk) 04:22, 18 September 2009 (UTC)

We need a collator article

The one piece of equipment that doesn't have a article is the collator. The major collators were the IBM 77 and IBM 85/87; the IBM 188, from 1961, was the last, as by then computers were coming in. [5]. The first collators were developed for the U.S. Social Security Administration.[6]. Collators do matching and merging of previously sorted decks. They can combine cards from two input sources, or keep them completely separate. These were the machines that added "join" capability to unit record processing, which made the whole process much more general and allowed for more error checking.