During the early 1960's, the factory data collection systems consisted of terminals with electromechanical badge and punched card readers plus knobs to turn or levers to push to a set of numbers for entry as variable data. The terminals were connected by heavy, stiff, and thick cable to receiving units that punched the raw data into paper tape or cards. Later this punched media would be read into the main frame for the editing and correction runs to finally create clean data for the batch processing programs which updated master files and produced the reports needed by management to profitably run the plant. Though this sounds cumbersome and expensive, it was still much better than the very common method of having the workers write their results on pieces of paper, collect that paper, and have the keypunch operators try to decipher the handwriting to create the punched cards that were entered into the edit and correction runs.
Roy Score installed many of these systems as the top salesman of Friden Collectadata systems. Although Roy was not computer knowledgeable, he was creative and observant enough to have many better ideas than were being used. Since Friden would not implement his thoughts, he founded DPI with the following as some of the major system requirements:
1. Cabling was and still is one of the major expenses and problems to install. Instead of pulling the 90 pair cables of the day, it seemed only reasonable that the telephone lines that were already all over a plant could be used. Data transmission over two wire lines up to 12,000 feet with no modems, terminators, or branching restrictions was a requirement met by the DPI T/R line. In many cases, pairs from the cabling used by the system being replaced were used for an additional savings.
2. The dirt, grease, and sometimes almost metallic atmosphere in the plants where terminals reside created havoc as the badge and card media with its attached garbage was dragged across the mechanical readers. The DPI terminals would be built with all electronic components, using optical readers, and with none of the parts open to the outside other than the slot for inserting the badge. The terminal contained only one moving part which was used to scan the punched card. The card was held stationary on a flat glass plate outside the unit while the scanner on the inside moved the light source and photocells to read the data. The badge was read by stationary photocells in the badge slot. The badge slot was vertical to allow any dirt that might enter to fall through.
3. In those days the typical factory worker was not familiar with nor trusted computers. Terminals were treated roughly and quite often used by very strong men wearing heavy gloves. We referred to him as "Thumbs Handleman" who could push his finger through a concrete wall at will. The first DPI terminals had large buttons with a two pound force required to push them.
4. When Data Collection systems eliminated the time card by using the employee's badge, the badge became very important to that employee. Without it, his pay was threatened. So they became very upset if the badge was not within their control. The Friden badge readers held the badge by running a pin through a hole in the badge. At least one case of badge retrieval by channel lock pliers was known. The badge in DPI terminals was held by rubber bumpers so that if the system did not release the badge as it should, the operator could retrieve the badge with no damage to the reader or his temper.
5. The DPI 2of5 code badge also provided improved features. Other systems used Holerith coded badges which had to be inserted deep into the reader to read all numeric punches, had no error detection mechanism, and had little room for picture and logo. The DPI badge only required use of the lower half of the badge leaving plenty of room for pictures, any kind of clip, and had built in error checking. In addition the first badge readers were built so only half the badge was in the slot meaning the employee could keep a full grip on the badge as he clocked in and the clip never interfered with operation.
6. The tutorial instruction mask on the terminal for transaction lead-through cut training time and memory exercises for the users. A unique application was a plant in northern Ohio who employed quite a few people who could not read. By color coding the punched cards and inserting pieces of transparent plastic of matching colors over the mask bulbs, the terminal became user friendly (before the term "user friendly" was coined). In addition, of course, the masks were created by/for the customer to contain their preferred wording, language, or pictures.
7. The communications line rate of 300 characters per second was 5-10 times as fast as the competition. Today that does not seem very fast, but with the T/R protocol and the zero turn-around time of the terminals, we could exceed 600 T&A transactions per minute on a line. Some of the more modern protocols and turn-around times do fewer than that at 1200 characters per second.
8. The addition of a computer as the central controlling point of the terminals created many immediate improvements to the data collection arena. For example: A. The batch edit/correction runs on the punched cards or paper tape were eliminated as those edits were now made while the source of the information was still standing in front of the terminal to give corrections. B. Changes to the terminal transaction prompts, sequence, and input became easily implemented at a central location. Previously such changes were accomplished with a soldering iron at each and every terminal. Even later (early '69) when we ran a head-to-head pilot against an IBM system controlled by a 360-30, our effective and simple AIDE language allowed changes in five minutes compared to two hours for theirs. C. Terminal malfunctions could be detected, reported, and the FE dispatched, in many cases before someone even needed to use the terminal.
9. There was no attempt to work at the threshold of hardware technology. Reliable, proven components were configured to create STATE-OF-THE-ART SYSTEMS.
10. We knew the purpose of the system was Data Collection using a front end communications transaction processor. The hardware and software were specifically architected to this purpose. We were not attempting to compete in the data processing field. We emphasized that the main frame manufacturers did a great job at data processing and that function should continue to be done there. "Let each component of a system do the function it does best and the whole system will function best."
Home | Logos |
Lists | Pictures
| Nicknames |
Happenings |
| People | Trivia
| History | Principals
| DPI Stock |