Grady Hospital - Goat or Hero?
Dec 17, 2019
As BusinessCom’s resident “old guy,” I’ve been asked to share some of my memories of networking in days of old. I began with facsimile technology, Graphic Sciences FAX , then moved on to early data communications A dollar a bit – big as a shoebox with everything from dial-up modems to multiplexors. In this article we’ll ride the technology wave through the very early days of Ethernet technology.
Ethernet was invented in large part by Robert Metcalf while working at XEROX PARC about the time I was getting out of high school. Metcalf founded 3Com in 1979, a company that will play a later role in my story. Ethernet was named for the mysterious substance postulated to exist as a medium for electromagnetic waves – the luminiferous aether, a medium that has since been fully debunked. Ethernet, however, continues to play a huge role in our networks, though it has migrated and evolved into something very different from how it began.
Ethernet
When describing or explaining Ethernet as a young sales guy, I would tell clients to imagine a long hallway with many office doors. When you had information that you wanted to send to another office, you would randomly yell out the door, the office number to which it was directed and the information you wished to deliver. If nobody else was yelling out their door, your message was delivered to all the offices, and the office to which it was addressed, would listen to it or receive it, while the other offices would ignore it. If two or more people yelled out their information at the same time, they would all back off, wait a random period, and then try again. The technical term for this is CMSA/CD or “carrier sense multiple access with collision detection. Many workstations or devices could share a single medium, such as an Ethernet cable to communicate with each other at what were very high speeds in those days – 10 Mbps. If you think this through, you realize that as you add more offices (devices) and more people yelling out the information (data traffic) you get more and more collisions and thus reduced efficiency; but in the early days when traffic was mostly alphanumeric with no images, voice or video, this wasn’t much of a problem.
Bridge Communications
My introduction to Ethernet came when I was approached with an opportunity to interview with Bridge Communications Corporation, a very early adopter and developer of the technology. I had always been in sales, but this was a position for a System Engineer. I knew nothing of Ethernet, so I headed to the local library (no Google in those days) and tried to learn a little about it. There was very little information available. I was also informed that I needed to understand a little about TCP/IP, which I learned was a networking protocol. Having some familiarity with Burroughs and Honeywell poll & select, X.25, and IBM’s 3270 protocols, I knew what a protocol was. Except for X.25 which was quite complex, those protocols were quite simple compared with TCP/IP. The first interview with Craig, the sales guy I would be working with went well. He was opening a new office and needed a System Engineer. He was new to the technology as well, but he was somewhat technical and a fast learner. I knew how to work with customers, and I had learned nearly as much as him. What he really wanted was an indentured servant, which I didn’t realize at the time. In any event, I gained his approval. I did OK with the Regional Sales Manager who probably knew even less than I did. Finally, I had to have a phone interview with the Manager of System Engineering in the California headquarters. It did not take him long to figure out the limits of my knowledge regarding Ethernet and TCP/IP. The interview was going downhill, and the situation looked bleak.
Fortunately I understood enough of what the company was planning to do, that I found a key to open the door. They were taking the various computers and minicomputers of the day, such as Digital Equipment Corp (DEC), Data General, Wang Laboratories, Prime Computer, Tandem Computers, Hewlett Packard, Honeywell, etc. and connecting dumb terminals to the host computers using Ethernet instead of individual runs of RS232 cabling. Thinking fast, I asked him what the biggest problems were that they faced, and it turned out that interfacing with all these different computers was a big challenge. Bingo! I had been working with these platforms selling modems, multiplexors and other networking devices, as well as monitoring their traffic with analyzers, and learning the idiosyncrasies of their signaling techniques so I knew these devices. I made the pitch that I was his guy, because I could hook that stuff up. To me it was only a matter of learning his stuff, and once I did, I could hook his stuff up to the other stuff. He was convinced, and I got the job. Whew! It turned out to be a great job in may regards.
The Technology
I started learning the technology, which then was based on the 10Base5 or “thick Ethernet” standard. Basically, you ran a thick Ethernet cable throughout the building or campus, and at various places you tapped into it, installing a a transceiver which was connected to the device that needed connectivity. The tapping device looked like a candle with a little drill bit sticking out the end. You would drill a hole in the thick cable and a “vampire tap” which had a spring-loaded pin would go into the hole and make contact with the center conductor. The transceiver also had a couple pins that went through the outside sheath and connected to a metal braid that ran through the cable. So, you’ve got a spring-loaded pin in contact with the center conductor and a couple pins touching the metal shielding just under the sheath. In this picture you can see a Cabletron transceiver connected to the thick Ethernet cable. Cabletron would move into other technologies, and I would run into them again years later.
A DB-15 or 15 pin cable and connector was used to connect the transceiver to the DTE (Data Terminal Equipment). Instead of having screws to hold the connector in place a slide mechanism was used. This slide design was clearly developed by drunk monkeys on LSD as it seldom provided a consistently secure connection. Bend it just a little, and it was useless. The DTE could be a wide range of devices, one of which was a terminal server such as this 10-port CS/100 with the cover removed.
What we called “dumb terminals,” that is terminals with a monitor and keyboard but no processor or memory, would connect via standard RS-232 (25 pin) cable & connector, to the terminal server. Sometimes a smart terminal, which meant an early PC like the Radio Shack TRS-80, or Wang Word Processor, running “terminal emulation” software that turned it into a dumb terminal, would also be connected. That would allow the PC to run as a local PC or word processor, and concurrently go across the Ethernet network to a host computer where it could operate like a standard dumb terminal connected to the host computer. Later models such as the CS/200 added text editors and simple UNIX programming so you could create a menu of hosts or dial-up modem banks, complete with dial sequences for the remote hosts, for the terminal to connect to. The user would make a menu selection for a host or dial up modem. I fancied myself quite the programmer, being able to write small menu programs to perform this function, but back to my story.
Grady Hospital
Early in my employment I was invited to go from the Clearwater, FL office where I was stationed, to Atlanta, Georgia, the regional office, to watch and assist experienced System Engineers troubleshoot a system in Grady Hospital which had recently installed a Bridge Communications Ethernet network that was performing poorly. Bridge Communications developed a range of terminal servers, gateways and bridges, and Grady Hospital had several of them. The CS/1-X.25 was a gateway that would connect hosts using that protocol or connect to X.25 wide area networks. It was quite a bear to configure. The CS/1-SNA provided a connection to IBM hosts using 3270 emulation so that the dumb terminals looked like IBM 3278 terminals to the IBM FEP or Front-End Processor. The CS/1 was a high-density terminal server that provided 32 ports to connect terminals or host ports. The terminals would be connected to CS/100s and CS/200s scattered throughout the facility. The IVECs card was designed to fit inside the popular DEC (Digital Equipment Corp) VAX computers so you didn’t need a CS/1 with all those cable connections. It was basically a terminal server on a card.
I flew up to Atlanta and joined the Regional Senior System Engineer, John at Grady Hospital. Not shown on the diagram was a network management computer than ran on a Sun Workstation and managed the entire network. Everyone was huddled around the Sun workstation, looking at diagnostics and running tests and trying to figure out why performance was so poor. Having no clue at that time as to what they were doing, I went into the computer room next door and started poking around. I found the end of the thick Ethernet cable which was terminated with a special 50-ohm termination connector. One thing I had learned early on was that the Ethernet cable was supposed to have 50 ohms of resistance between the center conductor and the outside meshed metal sheath that the vampire taps connected to. I knew how to measure this, so I pulled out my trusty ohmmeter, took the terminator off and checked the resistance. It was nowhere close to 50 ohms. I put the terminator back on and went over to the other room where the Sun workstation was located and found everyone in a complete uproar. When I could finally get John’s attention, I told him about the problem with the resistance and learned in the process that by taking off that terminator I had brought the entire Grady Hospital network down. Oops. Time to go to the cafeteria for a sandwich.
It turned out that there were a bunch of transceivers underneath the raised computer room floor and some of them were bumping up against the metal supports, grounding them out, and this was creating the problem. The final fix, if you can believe this, was to put every single transceiver in the network in plastic bags so they couldn’t come into contact with the metal support uprights, or anything else metallic. I was forgiven for my “original sin” in taking down the entire hospital network, going from goat to hero over the course of a day or two, as the network fully stabilized after that.
As time went by, I became proficient with the technology and assisted the sales rep by doing everything he didn’t want to do. In some ways, he was like me, preferring to do all his own technical sales presentations rather than use his System Engineer. Since I came from a sales background, this was a bit of a struggle for me. I was recently chatting on Facebook with a former System Engineer, Eric, now Vice President, Global Systems Engineering with iDirect, one of our most important partners, who supported me as a System Engineer with a couple different employers, starting with 3Com. I jokingly recalled how I became dangerous once I had a little knowledge, as I too preferred to do my own technical presentations. He, all too quickly, agreed. I asked him to return the screwdriver he took from me years ago, and he said he still had it but was afraid I’d hurt myself. Sigh. In the words of Rodney Dangerfield, I get no respect!
I have many great memories of working for Bridge Communications. We made sales calls to NASA where I learned that all the rows of computers combined, in the large building that was the headquarters for the Apollo program, had almost the same processing power as a Radio Shack TRS-80 or Trash 80, as we called it back then. I installed a large campus network for the University of Central Florida outside Orlando. I loved that account because I could ride my motorcycle to call on them and didn’t have to wear a suit. Unfortunately, I had a motorcycle accident when I was cut off by a driver with no insurance one night and I can tell you that lugging around CS/200 terminal servers while on crutches is no easy task. Did my sales guy help me? Ha! He collected the commissions… It’s tough being a system engineer when you do all the work and someone else makes all the money!
Bridge Communications eventually merged with 3Com Corporation, one of the early pioneers of personal computer networks and thinnet Ethernet. Ethernet continued to evolve and today bus architectures have been replaced by intelligent switching and Ethernet speeds are as high as 400 Gbps. 3Com moved me back into sales and transferred me to Virginia where I continued to ride the technology wave that took me all the way to BusinessCom Networks and what is now the most exciting time in the broadband satellite industry in a couple decades. There is still a lot of technology to cover before getting to where we are today. This memoir ends about the year 1989, with me driving in snow for the first time in my life to visit a company with a large Bridge Communications network in Lynchburg, Virginia. More fun to come.
