The Rise and Fall of Email

By David Edgar

For the first time, the missing history of email and the technology war for the most significant development in connecting humanity since the invention of the telephone. Learn the shocking truth about email’s rise and ultimate corruption by the Clinton administration at the White House. Determine if email’s future, as we know it, maybe at an end.

Experience an unparalleled journey into technology and science, battling legendary companies, pushing past them to be the first to bridge all of email together. Learn the theories that would topple the industry’s technical masters and wreck their plans to charge money for every email message. See the tactical strategies of companies like IBM, Novell, DEC, MCI, AT&T and Microsoft as they all maneuvered to take over email. Watch as one after the other fall in combat, all failing to capture the great email prize. Realize how their disasters opened the door for the Internet to slip in and win the war.

Be on hand as email develops into one of the most important forms of communication so critical that when email breaks down, everything collapses. Go inside the email world of the Associated Press, World Bank, Postal Service, Avery-Dennison, Danish Ministry, and many others. Watch how the millions of email islands become connected forming the super continent needed for full globalization.

Witness White House email from its construction to its disgraceful failure. Learn the details of the White House “Mail2 Problem”, the first Clinton email scandal. This firsthand account uncovers the real truth about President Clinton’s secret “Project X” plan to confuse investigators and cover-up an email conspiracy. Discover where Hillary Clinton learned to corrupt email accountability and why she needed a private email server when she served as Secretary of State.

Calculate the real price of free email and how flaws in its protocol are subjecting all of us to terrible peril by allowing criminals, hackers, and politicians to go unchecked and unchallenged rampaging freely through one of mankind’s most crucial forms of digital communication. What everybody needs to know about email and the dangers that lurk within the depths of its creation.

• Language: English
• Publisher: David Edgar
• Release date: Feb 25, 2017
• ISBN: 9781370371044

David Edgar

David has 34 years of experience in the Computer IT community. He graduated from University of Maryland - University College with a Bachelor of Science in Computer Science in 1986. David started his computer career in 1982, at the age of 19, managing a microcomputer at Metropolitan Parts, the largest automotive parts wholesaler in the DC Metropolitan Area. David started his career in government contracting in 1986 by writing both the Operations and User manuals for the United States Information Agency IBM datacenter. He then coauthored the first GSA course in Computer Security in 1988. David started as a Digital Equipment Corporation (DEC) system support programmer at Naval Sea Systems Command (NAVSEA) in 1987. He built the first DEC program that monitored the operating system for resource usage and inactive processes. David built the first automated translation of Navy Accounting Data (STARS) between NAVSEA’s IBM datacenter and the DEC datacenter. David helped design and develop the first X.500 Directory Server with Soft-Switch for the Navy. In 1989, David designed and constructed his first commercial email gateway MBLink, providing a bridge between DEC-based email systems and cc:Mail. The key differentiator was that MBLink was the first gateway that did not require address registration. It algorithmically converted email addresses and would change the future of email integration. Electronic mail bridges originally took two to eighteen months to configure, were difficult to manage, and were only enabled for a limited number of users. With MBLink, the system was installed and fully operational in 15 minutes, managed itself automatically, and enabled unlimited users. David designed and/or built the first email gateways for 3COM, Microsoft Mail, Lotus Notes, Novell’s Global MHS, and SMTP. During this period, MBLink was the primary email bridge used at the White House from 1992 thru 2000. In 1999, David was the founder of Altarus Corporation. The company was focused on the development of a secure system for moving application transactions in real-time across wireless networks. David invented an advanced network, data processing architecture and received US Patent 6,912,522 – “System, method and computer program product for optimization and acceleration of data transport and processing”. Altarus became the principle wireless consultant for Hewlett Packard and was a Symbol Technologies Platinum Partner. Worked with NIST to receive the first FIPS 140-1 certified mobile platform (Certificate 255). Designed and developed the first fully integrated mobile biometrics security authentication system engineered to perform perimeter security using fingerprints. This security product was runner up in the Best New Technology award at FOSE 2002. David was the Principal Investigator for a Cooperative Research and Development Agreement (CRADA) with the Space and Naval Warfare Systems Center in San Diego (“SSC Pacific”) called “Hastily Formed Secure Data Networks”. The purpose of the CRADA was to investigate methods and processes that could be used to quickly assemble a secure data network during an emergency event. David was also the Principal Investigator for a follow-up CRADA with SSC Pacific called “Low Bandwidth Wireless Network” (LBWN). The purpose of the second CRADA was to research the use of various network protocols and determine their overall effects on network performance, their general compatibility with Command & Control (“C2”) data, and their practical usability in low-bandwidth wireless environments.

Book preview

Cover Art by Kimberlee K. Edgar

Edited by Elizabeth P. Bohon

This book is dedicated to the most wonderful person I know, Elizabeth Bobbie Garland Edgar, my mother. For my entire life, she has loved, supported, and believed in me when all others lost hope. She was always there from sleeping in a chair in the hospital when I had major surgery at age ten to standing me up when my career had taken some rather dark turns. Love echoes through time and shared hearts can never be separated.

Chapter 1 – The Great Email War

Technology can be mankind’s greatest friend or its greatest enemy. The judgement of which is always dictated by time. As a scientist, I see this as the World Technology Ladder. This ladder leads us from the past to our future. Each rung of the ladder represents technical evolution from primitive tools to satellite defense systems. A scientist’s job is to build the next rung on our piece of the ladder, our field of study. If the rung is correct, it supports mankind’s movement up the ladder. If the rung is incorrect, it is always crushed under the weight of time. If the rung is built too high or placed too soon, mankind can easily slip and destroy itself.

This path to the future is where the technology wars rage. There are a thousand opinions on how to build the next rung or whether it should be built at all. This is especially the case in the computer software field. Computer software science is not bound as many sciences are to the natural laws of the universe. It is a virtual world completely of our own creation, and within it, anything is possible. The protocols and programs that we create define this universe. What we do in this universe of our own creation and how we do it directly impacts man’s ability to progress in the real universe.

Some computer technologies have good science behind them, some have good business behind them, and occasionally, some have both. When business feeds technology, the progression can be radically accelerated or dangerously restricted. The conclusion of which is dictated by the principle: What is good for business, may or may not be good be science. The essence of science is the search for truth. Truth and business have never been known to be good allies.

Technology at too fast a pace can destabilize business models and significantly reduce profits. This is one of key factors that determine whether a civilization can absorb a certain level of technology. Similar to Star Trek’s prime directive, introducing advanced technology into a primitive culture can destabilize a society. What is interesting is we do not need aliens to come to Earth to have this happen to our civilization. We are more than capable of doing it to ourselves and at a much greater probability.

The specific technology rung that we will cover in this book is the war for email supremacy. It will be fought by many different companies. All believed email to be the key to monopolize or prevent monopolization of their other products, such as operating systems, network software, desktop applications, and so on. Email was the first computer application whose sole function was to promote a new form of electronic interaction between people. This new form of interaction would alter the entire dynamics of human communication and would accelerate mankind’s ability to work together. The human race would seize upon this and the fulfilment of this need would drive the war to come.

In the mid-80’s, for two people to communicate in different locations or from different companies, required a face-to-face meeting, a printed letter or report that had been mailed or overnighted to the other person. You could pick up the telephone, but the amount of information that could be communicated was limited and it certainly did not include spreadsheets.

I cannot recount how many times that I traveled to the airport late at night trying to get something on a plane. Few people knew at the time that at Dulles Airport (IAD) in a remote building with a poorly marked door, packages could be dropped off at FEDEX up until 9:30PM. Walking in, you were literally standing in the package processing facility watching packages go by on the conveyor belt. Years later, as more and more people discovered the secret door, FEDEX would have to construct a storefront to deal with the crowd of people that would show up between 9PM and 9:30PM.

One of the first technologies to accelerate paperwork faster than airport trips and overnight packages was the fax machine. I remember helping install the first ones back in 1987. It was a machine of mystery and magic to most employees. After one installation, a senior staff member came into the room with a frustrated, angry expression.

She said, The fax machine is not working.

I responded, What error message did it give you?

She responded, I didn’t get an error message.

Curious, I asked, What makes you think it didn’t work?

She explained, I did everything I was supposed to, but the paper is still here.

Everyone in the room was stunned for a moment and I said, Damn that matter disintegrator/re-integrator; it’s been a problem all week. This produced much laughter and a thousand and one jokes such as Don’t get a fly caught in the fax machine; your customer won’t like what comes out.

The problem with the FAX documents was, except for printing them out, they were useless. A FAX is nothing more than a scanned image (picture) converted into a file and then sent using a basic file transfer protocol. You could get the file and try to convert it into something usable like simple text, but the results were even more hideous than the reintegrated monstrous paper fly. The image quality was just too poor and Optical Character Recognition (OCR) technology was still primitive. If you could not pull out basic text, then word processing and spreadsheets were totally out of the question. Something much more advanced was needed and that would be email.

Email did exist in the workplace, but at the time, it was limited to only people that had accounts on the mainframe computers. Access was dictated by the distance that a terminal could log in. Everybody had dumb terminals: the old green screen and, for the luckier ones, amber. A dumb terminal is the equivalent of your current PC monitor: it can’t do anything unless it is plugged into a computer. I remember when I acquired my first amber screen in 1984. I had the only one in the whole organization because I was the computer guy. You can’t imagine the jealousy and animosity that it generated from the green screeners. I had to buy a second one and deploy it as a group machine out in the Accounting Department to quell the riot it generated.

Now, for the purist out there, we never considered a VAX as a mainframe. The classic definition was that only the older equipment, such as the IBMs and Data Generals, were mainframes and DEC was classified as a minicomputer. This was because VAXs could range from a MicroVAX, which was the size of personal refrigerator, to the high-end systems that were the size of a small minivan. For the purposes of this book, I will be referring to all DEC and IBM systems as mainframes because they represent something more than just a computer size or processor distinction.

Mainframe in my context represents the old computer way of doing things as opposed to the new PC way of doing things. With mainframe computers and minicomputers, software programs executed with much higher efficiency and at extreme levels of reliability. Computer operations were highly organized and managed. Software upgrades would take a year of planning and sometimes required very expensive implementation plans that could go on for months. When a computer cost a half a million dollars or more, there were no spares. Everything that was done on a live machine, serving a host of other critical functions.

PCs on the other hand were only a few thousand dollars each, so upgrades could be performed on non-live equipment and spares were plentiful. PCs generally only served one function and could be sloppy. If the PC failed, the machine was simply rebooted. As a result, the high software quality, efficiency, and reliability standards of the mainframes was abandoned.

In 1987, I would have my first serious exposure to email architecture and general mainframe usage. I received a VMSmail account on a Naval Sea Systems Command (NAVSEA) Digital Equipment Corporation (DEC) computer system known as a VAX. With my NAVSEA VMSmail account, I would only send messages now and then. Since I was sitting next to the VAX datacenter, I only needed to walk a short distance to talk to anyone; so, it really served no function. Sending email outside of the datacenter was never done because reaching remote locations was complicated and many of the destinations required considerable knowledge of Navy network architecture.

Email was inherently tied to the network. One of the key components of any mail system, electronic or otherwise, is the concept of a location. With the first real business email systems, there was only one location and it was the mainframe. Every company, organization, and department had their own little island. Computer networks came along, organized and connected different groups of similar islands together and established the concept of a network location. These locations would create the network maps that would define the known world for email. The bigger the network, the farther email could reach.

The Email War focused on how to connect all the different types of email islands together. This required bridging different networks and integrating incompatible email protocols. If all email could be connected together, companies and people could communicate and exchange information in great quantity and it would be measured in minutes, not days or weeks. I would find myself in complete scientific disagreement with the industry’s way of bridging email. If they had their way, it would cost more to delivery electronic mail than it would postal mail.

The Age of Email hung in the balance; to usher it in required solving the bridging problem in a completely different way. I would theorize an alternate scientific method for integrating email that was simple, reliable, and cheap. These are the three primary hallmarks of technology that make it worthy of being a rung on the ladder. This foundation allows a rung to hold the weight of time and be a solid connection to the future. I would interject myself and my theories right into the middle of the Email War to alter the outcome. I would fight each battle in the trenches of the datacenters and I would win each fight at the software protocol layer.

I started as a simple soldier in one of the thousands of private armies that served the Federal Government performing computer and network services. I would rise to be a warrior, leader, and pioneer during the great Email War when it raged across our planet from the late 80’s throughout the 90’s. The war would encompass the entire computer landscape and dictate all of our futures. I would lead an insurrection against the industry’s order of things and it would affect everyone from the smallest user to the President of the United States. The next level of human communication was at hand and it could not occur until the Email War was resolved.

Chapter 2 – Ways of the Warrior

To fight the Email War, I needed to acquire the skills and training necessary to rise above the herd to see that the path was wrong and email’s future was heading off of a cliff. I discovered that to acquire unique weapons, generate opportunities, and outmaneuver enemies in order to win battles is not an exercise for the meek. Developing a confidence in yourself and your own abilities was absolutely critical because no great idea arrives with a whisper. It must strike with thunder or no one will ever hear it. I came from a family of warriors and with their spirit and my talents, I would push and claw my way through the naysayers and doubters and would not stop until everyone heard the echo of my thoughts and dreams.

This tale begins shortly after I graduated college with a Bachelor’s degree in Computer Science in December 1986 from the University of Maryland, University College. I already had many adventures up until this point. I had been the system and network manager for three years for the largest automotive supply warehouse in the DC Metropolitan area. I had also worked with my father, Mallory Freeman Edgar, in his government consulting business. My dad was a security expert and would often lend his skills to area companies and government agencies. When computer tasks would arise, I would end up doing them. On one such contract, I wrote the Operations and Users Guide for the United States Information Agency’s (USIA) IBM Datacenter.

In March of 1987, I had been attempting for several months to find a more stable profession than freelance government consulting. Anyone that has been in the consulting business knows that the pay is good, but seldom consistent. My wife, Kimberlee, was expecting and we had just moved to Crofton, MD out of our college group house. I was definitely feeling a little pressed. I wanted a job in software programming since graduating and when one of my father’s friends arranged an interview with a company in Tyson’s Corner, VA, I jumped at it.

The company was called AAC Associates Inc. (AAC) and I showed up for a series of job interviews. My first one was with the head scientist and computer guru, Ugur Koser, pronounced Ore Kosher. Ugur seemed very intelligent but a little stiff. He conducted the usual grind interview to determine my software programming capability. I spent about 45 minutes with him.

My next interview was with Warren Eder, the Vice President in charge of software projects. I found him to be quite interesting. His casual demeanor to complex computer programs was fascinating and quite unexpected.

One of the problems that I encountered time and time again in science and technology was the stuffiness factor. The brotherhood of the intellect that routinely chastised and belittled those that knew less was rampant. This attitude of superiority perpetuates a system that spoils science and takes the joy out it. I found science to be fun, interesting and a wonderful way for me to explore some of the mystical puzzles of man’s future. Snotty scientists are seldom fun to work with and I found them to be closed-minded when any of their preconceptions are challenged. It becomes more about their egos than any type of science puzzle.

Warren was anything but stuffy. Concepts just flowed out of him and there was a joy and wonderment to it. He freely shared information and thought. His ideas shot off in different directions like fireworks, but then somehow found their way back into a single point of technical direction. He was friendly and vibrant and all things in the universe for a moment seemed possible. Wow! I was impressed. I thought, Warren would be a wonderful person to work for and it would give me an excellent opportunity to pick his brain.

My next interview was with the President of the Company, Anthony A. Carlson (Tony): smart, Italian descent, tough as nails, and definitely not for the timid. He interviewed me for about thirty minutes trying to twist me this way and that. This was not my first time at the rodeo and I was seldom intimated by the bulls. I rode it out and he seemed frustrated.

Next, he handed me a thick binder and said, Start at the beginning and tell me what you know about each subject. I opened up the binder. It was a list of technical terms and acronyms, about 150 pages long with 20 entries per page. I started going through them one at a time. Some I knew and some I didn’t. One thing was abundantly clear: Tony didn’t want to hire me and was purposely trying to trip me up. That certainly wasn’t going to happen. I was about 15 pages in and I knew I had to do something or there was no way I would get this job.

Midway through a page, I violently slammed the book shut making a loud smacking sound. I, then, stood up and threw the book down onto Tony’s desk and it hit with a crash. Tony seemed a little surprised and I said in a very confident, loud voice, Enough of that! Let’s get down to it. If you hire me, I promise you I will be the best employee you ever hire in your life. I will outperform everybody in your company, including yourself!

Tony smiled and said, You seem awfully confident.

I stared directly into Tony’s eyes and responded, I’m confident only because I know what I say is the truth. I will do unbelievable things for your company. All you have to do is give me a chance and I promise you will never regret it.

Tony was taken by my outburst and I was offered the job several days later. Tony would tell me years later that he was trying to get rid of me because the person that recommended me was not very technical. The industry was chock full of people claiming to be technical, but were not. AAC could not believe that this person would actually recommend somebody with any real technical skills. My dogged pursuit and outburst had convinced Tony that I did have some skills and he loved my attitude.

I was hired specifically to work on an upcoming email project with Naval Sea Systems Command (NAVSEA) in Crystal City, VA. However, the contract funding was delayed and until it started up, I would have to perform other contracting duties. I was assigned three days a week at NAVSEA providing system programming support and I was assigned two days at the National Library of Medicine (NLM) providing local area network (LAN) support. At NAVSEA, I would be working with mainframe VAXs and wide area networks (WANs). At NLM, I would be working with Personal Computers (PCs) and local area networks (LANs). I did not know at the time that the fusion of these two skill sets would dictate my future to come.

I loved working for NAVSEA. I was an Army brat. My dad was a career officer and I grew up on many bases: Ft. Sill (Oklahoma), Ft. Riley (Kansas), Ft. Meade (Maryland), and 7th Army Heidelberg. Working for and interacting with the military was both familiar and comfortable. Ironically, growing up, I favored the Navy over the Army and this had transformed into a lifetime contest and debate between my father and me. Consequently, for me to work for the Navy allowed me to perpetuate this disagreement on service branches to a whole new level, as well as, indulge my love for the Navy. Growing up, my dad would bring home all the Jane’s Fighting Ships books he could get his hands on. I would spend hours going through the specifications of each ship. Two things I shared with my dad were love of the military and love of our country.

The Edgar’s were a military family. My father, Capt. Mallory Freeman Edgar, was highly decorated serving with the 1st Calvary in Vietnam. He received many citations including the Silver and Bronze Star. My dad’s unique capabilities in intelligence and security quickly positioned him into Military Intelligence where he would serve until his retirement in 1978. After his death in 1993, he was buried with honor in Arlington National Cemetery.

My great uncle was Major Thomas Callison Edgar who served George Patton as a Tank Destroyer Gun Company Commander for the 3rd Army. He was terribly wounded at Bastogne, Belgium during the Battle of the Bulge losing both his legs. Even with his injuries, he would go on to serve the State of West Virginia first as the Delegate of Pocahontas County and then as a leading force in the management of agriculture, forestry, and natural resources statewide.

My great-great grandfather was Captain Alfred Mallory Edgar who served with Jackson’s Stonewall Brigade – 27th Virginia Infantry, Company E The Greenbrier Rifles. He was with Jackson on Henry Hill during First Manassas. According to Alfred, who was there, Brigadier General Bee while trying to encourage and reform his brigade yelled out, Rally behind the Virginians who are standing there like a stone wall! General Bee would fall mortally wounded moments later. Alfred would go on to fight in every major battle until his final capture on May 12, 1864 after the Battle of the Wilderness (Spotsylvania Court House). Captured, he and others would endure abysmal conditions in a prison in Hilton Head, SC. Through their terrible suffering and ultimate survival, this group would become known as the Immortal Six Hundred.

Alfred’s grandfather was Capt. Thomas Edgar. He served with George Washington and was at Yorktown for the surrender of Lord Cornwallis. Thomas was the first surveyor of Greenbrier County and would survey a forty-acre square that would become the town of Lewisburg, WV. The Edgar’s were one of the first Virginia families. This Edgar family information is taken from The McNeal Family Record by Betsy Jordan Edgar, McCLAIN PRINTING COMPANY, 1967 and the unpublished Memoirs of Captain Alfred Mallory Edgar.

Prior to Virginia, our family history traced its roots back hundreds and hundreds of years through English and then later through Scottish History with our own Coat of Arms and the whole bit. Military service was not just some career option, it was a revered practice through which our family demonstrated love of our country through sacrifice and extraordinary achievement. Greatness for my family was nothing more than a simple byproduct of extreme dedication to service and country.

I did not have the required health and physical capacity to join the military. Therefore, being able to work as a scientist for the Navy was emotionally satisfying on so many levels. It was my chance to serve my country and continue the Edgar tradition. I would do everything in my power to serve with complete honor and distinction. I would intertwine my love of country with my love of technology and make sure that the United States would advance as fast as I could possibly make it happen.

At NAVSEA, my first task was to build a FORTRAN program that would monitor all the Digital Equipment Corporation (DEC) VAXs for idle processes. A computer process that is not doing anything is wasting valuable mainframe resources. This could include everything from a user forgetting to log off their terminal to sloppy application software. Talk about getting a perspective change: I was building a program that monitored other programs and tracked their resource usage. In its construction, I gained an understanding of all the various pieces and parts of the VAX and more importantly, how they related to each other. I could see the entire computer process and I knew what efficiency really meant in terms of the different resources and how they were used for an end-to-end computer operation.

While I was working on this first project, Warren and Ugur would visit the Crystal City site periodically and check on my progress. On one such occasion, Ugur was on-site doing his usual walkthrough. After he disappeared for a few minutes, I started hearing a strange noise, as if some type of battle was going on. Curious, I got up and walked across my office around a room divider and there was Ugur. He was sitting at the SF13’s desk, playing a computer game. SF13 is a high government employee grade and each department would have one of these senior people. Since they are senior members of a department, they usually had the best equipment. Ugur had decided that he wanted to try this new game out on the SF13’s high-end personal computer (PC).

Ugur was playing a game called Ancient Art of War in which different historical battles could be simulated and then fought out on the screen. For computer gaming in 1987, it was remarkable. Many of the strategy games at the time were non-graphical and usually consisted of a text-only interface, such as Zork. With Ugur’s game, you could actually see your soldiers fighting. I started talking to Ugur about gaming and gaming system design. I found him to be wonderfully intelligent and he loved technical toys as much as I. This was to be the start of a close friendship and a technical alliance that would span throughout the upcoming Email War.

My next project at NAVSEA was a bridging application. One of the primary functions of NAVSEA is the accounting management of the Navy. The accounting system called Standard Accounting and Reporting System (STARS) was on the IBM mainframes. The data needed to be transferred into VAX-based accounting programs as part of its general processing. In order to do this, the STARS data was copied onto an IBM Backup tape in the IBM datacenter at the top of the building. It was then hand-carried and mounted as a foreign tape in the VAX datacenter on the first floor. This was not very efficient, so NAVSEA acquired a piece of software called HASP-Link that would allow files to be exchanged between IBMs and VAXs without having to use the stairs. Unfortunately, when NAVSEA tried to move the STARS data across the HASP-Link, the resultant files were completely unusable. My job was to figure out why.

The problem turned out to be that the file systems between the IBM and VAX were radically different and HASP-Link had no idea how to compensate for the incompatibilities. File systems are a piece of operating system software that determines how files are stored, handled, and interpreted. The VAX had a really advance file system called Record Management System (RMS) that supported a complex structure that was used for indexing and controlling large files. IBM was still wrapped around their traditional view of the computer universe which was an 80-character record. For those of you that do not remember when dinosaurs roamed the earth that is the same size as an 80-column punch card. The 80-column punch card was originally designed by IBM in 1928.

When NAVSEA mounted the tape on the VAX and marked it foreign, the tape subsystem automatically did the conversion, but the HASP-Link did not. Some form of that same conversion had to be done to make the project succeed. After examination of the HASP-Link software, there was no way to adjust it, the system lacked the intelligence to differentiate file types. If you cannot differentiate, you cannot make decisions in a computer. So, I invented a protocol and a process that would provide an additional layer of bridging software that would correct the problem.

I made my own special 80-column card and on it was my custom protocol for specifying VAX file structures. The IBM folks would put the lead card in their stack and my software would automatically translate the file structure accordingly. My data translation approach was successful and manual tape transfer was eliminated. I had successfully built my first data translator between different computers. Gaining this knowledge would be a key ingredient in things to come.

In addition to these projects at NAVSEA, I was also spending two days a week at NLM doing PC LAN maintenance and installation. I was responsible for configuring PCs and attaching them to different LAN network backbones.

I was also responsible for monitoring the various network bridges that tied everything together. NLM had a variety of LANs, WANs, and bunch of terminal and network protocol bridges. I periodically checked monitors and performed system tests to ensure that all the various components were functioning correctly. These bridges could be problematic and would require re-initialization every so often. I also routinely installed computers, configured network equipment, and ran cable.

I found running cables inside of a government datacenter to be very interesting. In datacenters, computers are on raised floors. Beneath these floors all the cables are run and air conditioning is pumped in. The NLM Datacenter always looked so clean and organized, but it hid a secret. Beneath the floor was a wire monster. So many dead wires had amassed that there was barely any room to run new cables. The problem was that it was easy to get authorization to run a cable, but very difficult to get authorization to remove one. Nobody wanted to take responsibility if the wrong cable was pulled out and something was screwed up. Over time, more and more dead cables accumulated until they filled up the floor.

At the NLM site, soon to be at the NAVSEA site and everywhere else, the PC invasion was gearing up. Users were receiving PCs on their desks to go with their terminals and an entire new group of users were being given computers for the first time. The next logical step was to connect all the PCs together using LANs and then to tie them into the mainframes WANs. These first pioneers pushed PCs to the limit of their connectivity: to see this gave me tremendous insight into this newly evolving technology. I began to see what worked, and more importantly, what did not work when trying to move information across a network.

I discovered that all of the network bridges were slow, unreliable, and prone to catastrophic failure. All bridges by their very nature are bottlenecks. You can think of a simple program error like a car accident. When there is an accident on the bridge, it slows traffic. However, when a software program fails, it is the equivalent to the bridge collapsing. No traffic can get across because the way is now completely blocked.

I noticed that the failure in the existing network bridge systems followed a general pattern. There would be small operational fluctuations on one side of the bridge or the other, such as a corrupted network packet. Corrupted packets resemble 500 piece puzzles that have a bunch of missing pieces. The software bridges failed to compensate for the variations and would get easily confused by simple