I cleaned out a bedroom closet a couple of days ago, trying to find room to stack even more books. I know, I have one of those e-readers, too, but I still like my paper books. Printed books provide instant access to information and entertainment and don't require a wall outlet or a charged battery to use. I have donated box after box of books to the library, but I never seem to have room for my newest addition. A problem I don’t have with my digital additions.
I no longer take print books to bed, though, as they are just too heavy and cumbersome to hold, especially the big hard-cover books. Besides, I need a reading light behind me and that keeps my wife awake while I fumble turning pages.
So, the Kindle Fire with its lighted screen is my current e-reader as I lay in bed waiting for the sandman to sneak up while I'm distracted with an engrossing read of some kind that I know I’ll have to go back and reread tomorrow. Besides, I also have my Internet available as well so I can wander off into FaceBook-land if I get bored with whatever I downloaded. Still, when I doze off and hit myself on the bridge of my nose with whatever I'm holding, it hurts less with a paperback than an aluminum-framed piece of hardware.
While digging around and tossing out mementos that have long lost their relevance, I came across a piece of hardware from the Asynchronous Age of Communication: my old dB Meter! What is a dB Meter, you ask? Well, maybe you won't ask, but for the die hard readers, let me tell you how our civilization has evolved because of this ingenious piece of test gear. It was to us IBM Field Engineering teleprocessing customer engineers in the dawn of computer communications as a bat to a baseball player or a microphone to a singer.
Without this piece of test gear, we couldn't prove TPC was the culprit that caused the new communications terminals to simply sit there, with their blinking lights on, teasing operators with the promise of communicating with a mainframe computer somewhere in the sky. [TPC, by the way, is The Phone Company, but then you have to know who Our Man Flint is and here we are back at square one.]
Back in those days, only some short forty or fifty years ago, when Teleprocessing was part of Data Processing - way before it was renamed to IT, Information Technologies – data interface communications was in its infancy. Data between computers was still handled mainly by delivery trucks which carried huge cartons of punched 5081 computer cards that had only 80 columns to store information, or magnetic tape reels the size of basketball hoops. They powered the computers that landed man on the moon. Think about that for a moment.
IBM originally had several terminals based on the old IBM Model B typewriters in the first, tepid attempts at real time data insertion and extraction, but when they made the Selectric Typewriter (c) look like a Borg, they hit pay-dirt. The Real time age of data processing pushed the old standard of batch processing into the dark ages in a matter of months. A new world, our world, emerged.
The first terminals in wide-spread commercial use were based on typewriters that were converted to respond to the pull of solenoids and magnets as well as the pressure from a human finger. Or sometimes a fist, as occasionally happened when they beeped and the Data Check light came on after an operator had meticulously typed in a long line of data.
In those days, hardly anyone beside secretaries could type. Most certainly not the newly assigned, inexperienced operators of the new computer equipment. Desk sergeants from police departments, tax collectors and county clerks, sales managers and line bosses all over the country trying to figure out what happened to the last delivery, were all new to the world of data processing, sorry, Information Technologies. It would be like having today's workers and managers sit down at the controls of an alien space ship with a cabbage as a keyboard.
The communications medium linking the new technology was the everyday, standard telephone line. Telephone lines were like politicians, however, they were all over the place, rhetorically as well as physically. Many people still remember their first home computers where a noisy modem would tie up your house telephone whenever you connected to the Internet. Dial up lines, however, were not for serious, full time data usage. Constantly connected terminals required a “leased line” that was always connected instead of one that made your family mad with a constant busy signal.
Those commercial leased lines had levels of service, just like the octane for gas in your car. Most data connections required a “C-2” level, which stipulated a certain level or standard required to ensure the terminal could actually send data to the computer on the other end of the telephone line. The voltages had to be of a certain level, and free of distortion or interference. The telephone line couldn't have clicks or pops, for instance, as the two devices might both think the other was trying to talk, or even worse, was trying to start a fight.
Telephone lines were notoriously unreliable as a standardized medium. It got to the point we would ask customers if it was cloudy when they were having troubles. It seemed anything on earth could cause problems. Ever hear of the Yellow Breasted Bit Snatcher? Heaven help you if one landed on your telephone line.
One of the biggest problems was signal level, measured in decibels, or dB. If the signal fell ever so slightly below accepted levels, the dreaded data check light would flash and that annoying little ding that still haunts grown men in their sleep would sound to let you know that everything you had just typed had failed to go anywhere. Why not hit the resend, you ask? There wasn't any such thing as resend. Messages were sent asynchronously one character at a time! The standard speed for a Selectric based terminal such as the 1050 or the 2740 was 14.5 characters per second. The line speed was usually 135 baud, - trust me, that's slow – although one version used for finance communication applications ran even slower on telegraph lines at 75 baud.
Buffered terminals were the second generation of terminals that actually saved humanity. Messages as long as 128 bytes could be created and stored and resent as often as needed to get through. Civilization was saved! A dedicated line could normally handle voice traffic or the 135 baud, but not the speed of the new buffered terminals and a new world was needed. Soon, line speeds were screaming at 1200, 2400, and even 4800 baud and telephone lines soon struggling to perform! Even the miserable dial-up lines could eventually communicate at 9600 baud! Jump ahead a couple of decades and, presto, here we are.
But without the venerable dB meter, I couldn't prove when there wasn't enough juice from the TPC to make our machines talk to each other. I used mine many, many times, and found many, many problems. The only serious drawback with the dB meter was sometimes it said the telephone line was just fine. That meant the problem must be in the circuitry of our beloved little engineering masterpieces.
Those were usually long, long nights. Back in the dark ages when it all started
1 Selectric
© IBM Corp
