Tymnet was an international data communications network headquartered in Cupertino, California that used virtual call packet switched technology and X.25, SNA/SDLC, ASCII and BSC interfaces to connect host computers (servers) at thousands of large companies, educational institutions, and government agencies. Users typically connected via dial-up connections or dedicated asynchronous connections. The business consisted of a large public network that supported dial-up users and a private network business that allowed government agencies and large companies (mostly banks and airlines) to build their own dedicated networks. The private networks were often connected via gateways to the public network to reach locations not on the private network. Tymnet was also connected to dozens of other public networks in the United States and internationally via X.25/X.75 gateways.
As the Internet grew and became almost universally accessible in the late 1990s, the need for services such as Tymnet migrated to the Internet style connections, but still had some value in the Third World and for specific legacy roles. However the value of these links continued to decrease, and Tymnet shut down in 2004.
Tymnet offered local dial-up modem access in most cities in the United States and to a limited degree in Canada, which preferred its own DATAPAC service.
Users would dial into Tymnet and then interact with a simple command-line interface to establish a connection with a remote system. Once connected, data was passed to and from the user as if connected directly to a modem on the distant system. For various technical reasons, the connection was not entirely “invisible”, and sometimes required the user to enter arcane commands to make 8-bit clean connections work properly for file transfer.
Tymnet was extensively used by large companies to provide dial-up services for their employees who were “on the road”, as well as a gateway for users to connect to large online services such as CompuServe or The Source.
Organization and functionality
In its original implementation, the network supervisor contained most of the routing intelligence in the network. Unlike the TCP/IP protocol underlying the internet, Tymnet used a circuit switching layout which allowed the supervisors to be aware of every possible end-point. In its original incarnation, the users connected to nodes built using Varian minicomputers, then entered commands that were passed to the supervisor which ran on a XDS 940 host.
Circuits were character oriented and the network was oriented towards interactive character-by-character full-duplex communications circuits. The nodes handled character translation between various character sets, which were numerous at that time. This did have the side effect of making data transfers quite difficult, as bytes from the file would be invisibly “translated” without specific intervention on the part of the user.
Tymnet later developed their own custom hardware, the Tymnet Engine, which contained both nodes and a supervisor running on one of those nodes. As the network grew, the supervisor was in danger of being overloaded by the sheer number of nodes in the network, since the requirements for controlling the network took a great part of the supervisor’s capacity. Tymnet II was developed in response to this challenge. Tymnet II was developed to ameliorate the problems outlined above by off-loading some of the work-load from the supervisor and providing greater flexibility in the network by putting more intelligence into the node code. A Tymnet II node would set up its own “permuter tables”, eliminating the need for the supervisor to keep copies of them, and had greater flexibility in handling its inter-node links. Data transfers were also possible via “auxiliary circuits”.
Tymnet, Inc. spun off
In about 1979, Tymnet Inc. was spun off from Tymshare Inc. to continue administration and operation of the network. The network continued to grow, and customers who owned their own host computers and wanted access to them from remote sites became interested in connecting their computers to the network. This led to the foundation of Tymnet as a wholly owned subsidiary of Tymshare to run a public network as a common carrier within the United States. This allowed users to connect their host computers and terminals to the network, and use the computers from remote sites or sell time on their computers to other users of the network, with Tymnet charging them for the use of the network.
Electronic Data Interchange (EDI)
Tymshare EDI, MD Payment Systems Company, MCI EDI Department
Tymshare was one of the pioneers in the EDI field. Under McDonnell Douglas, the Payment Systems Company continued that legacy and maintained its own network monitoring and support group. They used Tandem computers connected to a high speed data link using Tymnet as the connection and translation medium. Tymshare developed a bi-sync modem interface (HSA), a translation module to translate between EBCDIC and ASCII (BBXS), and a highly customized x.25 module (XCOM) to interface with the Tandem computers. Apparently, there was no TCP/IP equivalent service, so to continue use of this service after the shutdown of Tymnet, an ingenious solution was selected. A special version of Tymnet Engine node code which allows nodes and interfaces to communicate with one another and the rest of the network was created. Instead of relying on the “supervisor” to validate calls, a table of permitted connections was defined per customer to allow an incoming call to be made from the HSA interface to the BBXS interface to the XCOM interface and on to the Tandem computer. In effect, they created a “Tymnet Island” consisting of a single Tymnet node that accepted calls for a pre-determined list of clients. No supervisor needed.These islands of Tymnet have not only outlived the parent company, Tymshare, and the operations company, Tymnet, but also the Tymnet Network itself. As of 2008, these Tymnet Island nodes are still running and doing their jobs.
In operation, Tymshare’s Data Networks Division was responsible for the development and maintenance of the network and Tymnet was responsible for the administration, provisioning and monitoring of the network. Each company had their own software development staff and a line was drawn to separate what each group could do. Tymshare development engineers wrote all the code which ran in the network, and the Tymnet staff wrote code running on host computers connected to the network. It is for this reason, that many of the Tymnet projects ran on the Digital Equipment Corporation DECSystem-10 computers that Tymshare offered as timesharing hosts for their customers. Tymnet operations formed a strategic alliance with the Tymshare PDP-10 TYMCOM-X operating systems group to assist them in developing new network management tools.
Trouble reports were initially tracked on pieces of paper. This was until a manager at Tymnet wrote a small FORTRAN IV program to maintain a list of problem reports and track their status in a System 1022 database (a hierarchical database system for TOPS-10 published by Software House). He called the program PAPER after the old manual way of managing trouble tickets. The program grew as features were added to handle customer information, call-back contact information, escalation procedures, and outage statistics.
Access to PAPER became critical as more and more functionality was added. It eventually was maintained on two dedicated PDP-10 computers, model KL-1090, accessible via the Tymnet Packet Network as Tymshare hosts 23 and 26. Each computer was the size of 5 refrigerators, and had a string of disks that looked like 18 washing machines. Their power supplies produced +5 volts at 200 amps (non-switching) making them expensive to operate.
In 1996 the DEC PDP-10s that ran Tymnet’s trouble-ticket system were replaced by PDP-10 clones from XKL, Inc. They were accessible via TCP/IP as ticket.tymnet.com and token.tymnet.com, by both TELNET and HTTP. A low-end workstation from Sun was used as a telnet gateway; it accepted logins from the Tymnet network via x.25 to IP translation done by a Cisco router forwarded to “ticket” and/or “token”. The XKL TOAD-1 systems ran a modified TOPS-20. The application was ported to a newer version of the Fortran compiler, and still used the 1022 database.
In mid to late 1998, Concert produced an inter-company trouble tracking system for use by both MCI and Concert. This was adopted and the TTS PAPER data necessary for ongoing tickets was re-entered on the new system. TTS was kept up for historical information until the end of the year.
In January 1999, both XKL servers (ticket and token) were decommissioned. In late 2003 the hardware left onsite in San Jose was accidentally scrapped by the facilities manager during a scheduled cleanup.