Description

IBM's proprietary networking architecture, Systems Network Architecture, was developed in 1974. It is a comprehensive protocol stack for connecting resources and computers. SNA is a format and protocol description but is not software in and of it. SNA was made public as part of IBM's "Advanced Function for Communications" announcement in September 1974, which included the implementation of the protocols on new communications products. They were supported by IBM 3704/3705 communication controllers and their Network Control Program (NCP), System/370 and their VTAM, and other software such as CICS and IMS. Virtual Telecommunications Access Method (VTAM) is the mainframe software package for SNA communications. The IBM 3760 data entry station, the IBM 3790 communication system, and the new models of the IBM 3270 display system were introduced in July 1975, following this announcement. When SNA was designed, the computer industry had not fully adopted the idea of layered communication. It was difficult to maintain and manage because applications, databases, and communication functions were mixed into the same protocol or product.

Microcode Features

SNA was primarily developed by the IBM Systems Development Division laboratory in Research Triangle Park, North Carolina, with assistance from other SNA/SDLC-implementing laboratories. Manuals from IBM's System Reference Library and the IBM Systems Journal later made the information available to the public. It is still used extensively in numerous government agencies and financial transaction networks. There were approximately 3,500 businesses with 11,000 SNA mainframes in 1999. IBM has pulled the 3745/3746 communications controller, one of the most important pieces of hardware, off the market. IBM continues to support users by providing a hardware maintenance service and microcode features. Smaller businesses continue to offer the 3745/3746, its features, parts, and service to a large market. IBM also provides support for VTAM and the NCP that the 3745/3746 controllers require. SNA is evolving from true network architecture to an "application and application access architecture" as a result of TCP/IP's growing popularity. To put it another way, many applications still require SNA for communication, but IP is used to transmit the SNA protocols. This section has a list of references, links to related reading, and external links, but there are no inline citations. By using citations that are more specific, you can help improve this section. Learn how to remove this template message IBM saw itself primarily as a hardware vendor in the middle of the 1970s, so all of its innovations aimed to boost hardware sales. SNA wanted to encourage customers to develop or expand interactive terminal-based systems rather than batch systems by lowering the costs of operating a large number of terminals. The simple increase in the volume of work performed by the systems and the fact that interactive processing requires more computing power per transaction than batch processing would both contribute to an increase in sales of mainframe computers and peripherals if interactive terminal-based systems were expanded. As a result, SNA aimed to alleviate some of the challenges associated with operating large networks using earlier communications protocols as well as the main costs other than computers. The troubles included frequently an interchanges line couldn't be shared by terminals of various kinds, as they utilized various lingos of the current correspondences conventions. All-purpose communications interface cards were impossible to incorporate into terminals prior to the beginning of the 1970s due to the high cost and bulk of computer components. There was a hard-wired communications card for each terminal, but it only worked with that terminal and was not compatible with other terminals on the same line. The inefficient protocols that the basic communications cards were able to handle were ineffective. Compared to modern lines, each communications line required more time to transmit data. Broadcast communications lines at the time were of much lower quality. For instance, the overwhelming error rate made it nearly impossible to operate a dial-up line at more than 19,200 bits per second, whereas dial-up lines today operate at 56,000 bits per second; In addition, few leased lines operated at speeds greater than 2400 bits per second at the beginning of the 1970s these low speeds are a result of Shannon's Law in an environment with relatively low technology. Consequently, managing a large number of terminals necessitated a significantly greater number of communications lines than is currently required, particularly if multiple terminal types needed to be supported or if users desired to utilize multiple applications from the same location.

Computer Component Technology

SNA's goals were purely financial: increase customer spending on terminal-based systems and increase IBM's share of that spending, primarily at the expense of telecommunications providers. SNA likewise intended to defeat an impediment of the engineering which IBM's Framework/370 centralized servers acquired from Framework/360. A maximum of 4096 peripherals could be connected to each CPU, and each channel could handle up to 256 peripherals. Each communications line was considered a peripheral when SNA was designed. As a result, powerful mainframes could only communicate with a limited number of terminals. As a result of advancements in computer component technology, it is now possible to construct terminals with communications cards that are stronger and capable of operating a single standard communications protocol as opposed to a protocol that is extremely limited and only suitable for a particular kind of terminal. In the 1970s, a number of multi-layer communications protocols were proposed, with IBM's SNA and ITU-T's X.25 becoming the most popular later. The packet switching protocol defined by SNA is implemented by the IBM Network Control Program (NCP), a communications program that runs on the 3705 and subsequent communications processors. The protocol, which is a packet forwarding protocol, served two primary purposes.