Network Tests And IBM
IBM, in many respects, built its empire of network tests and its fortune by providing rock solid service for its customers. During this era, IBM also built much of its own network tests equipment. This equipment was made expressly for the use of its personnel in the maintenance of its products.
This closed community presented customers with few problems, thereby leading to the old expression "nobody ever lost their job because they bought IBM equipment." It also offered few opportunities to network tests equipment vendors.
If you were not a part of IBM's Big Blue family, you had a myriad of interesting, efficient, and innovative products, protocols, and technologies to choose from. Unfortunately they were all slightly different and generally proprietary. Found within this Tower of Babel were at least 12 well-known variations on the bisync theme and even more flavors of the IBM-inspired, CCITT-adopted data link control protocol. There were even several "standard" ways of representing numbers and characters.
In all, that period saw the use of approximately 1200 different ways of sending data from point A to point B. And with few exceptions, they were all mutually incompatible. This made interoperability a major challenge and network test equipment a major market. Enterprising network designers of that time could choose the best equipment from several different suppliers. On paper the composite network would look terrific. But when cables were connected and power was applied, success was never easily achieved. The vendors of networking components during this period had a term that was created to give the illusion that everything would work together. That term was functional compatibility. Freely translated it meant that one company's engineers acquired a piece of equipment from another company, took it apart, read its manuals, and built a new piece of equipment that seemed to work with it, at least sometimes. The myth of functional compatibility offered significant opportunities to test equipment vendors. Equipment designers, network managers, and maintenance groups all needed communications test gear whenever functionally compatible equipment wasn't. Protocol monitoring and emulation was the heart of this sleuthing process. Since access to this equipment was not always easy, the necessity for small, light-weight, battery-operated test equipment emerged. Test equipment manufacturers met this need with portable data line monitors capable of capturing, interpreting, and displaying protocol transactions. These protocol traces enabled network maintenance personnel to learn why the communications equipment wasn't communicating.
Network Testing Software
|