What is Systems Network Architecture (SNA)?

Systems Network Architecture (SNA) is a data communication architecture established by IBM to specify common conventions for communication among the wide array of IBM hardware and software data communication products and other platforms. Among the platforms that implement SNA in addition to mainframes are IBM's Communications Server on Windows, AIX, and Linux, Microsoft's Host Integration Server (HIS) for Windows, and many more.

The way in which products internally implement these common conventions can differ from one product to another, but because the external interface of each implementation is compatible, different products can communicate without the need to distinguish among the many possible product implementations.

SNA products recognize and recover from loss of data during transmission, use flow control procedures to prevent data overrun and avoid network congestion, identify failures quickly, and recover from many errors with minimal involvement of network users. SNA products also increase network availability through options such as the extended recovery facility, backup host, alternative routing capability, and maintenance and recovery procedures integrated into workstations, modems, and controllers.

History of SNA

In 1974, IBM introduced its Systems Network Architecture (SNA), which is a set of protocols and services enabling communication between host computers (IBM mainframes) and peripheral nodes, such as IBM's dedicated hardware boxes, the 3174 controller for 3270 type displays and printers, controllers for the retail and finance industry, and more. The mainframe subsystem that implements SNA was named Virtual Telecommunication Access Method (VTAM).

The robustness of the SNA protocol, the IBM hardware, and the transaction management infrastructure software supplied by IBM (CICS and IMS) made SNA the dominant protocol in the Fortune 1000 companies.

In order to understand the rationale of the many functions and services in SNA, you must understand the computing environment at that time. Prior to 1974, data processing was batch-based. Batch means that data was recorded on paper, usually on predefined templates, and was keyed into media (like punched cards) readable by the computer system. The computer department executed various programs on the data. The final result was a printed report.

Around 1974, transaction processing was introduced. People used terminals to key in the data directly and receive the output for their inquiry instantaneously. To implement transaction processing, networking infrastructure was put in place. The carriers at that time were geared to supply voice services rather than data service, so communication lines were slow and unreliable (in the range of 9600 bits per second).

The human ear can tolerate small errors in telephone lines, but computers cannot. Even a missing bit, or an extra bit, in a data communication line can be catastrophic. Try to imagine what might happen to your bank account if the ATM you use receives a garbled message.

In the early 1970s, computer memory was a scarce and expensive resource. Devices with 16 KB of memory were common in the computer industry. These devices were slow compared to the CPU speeds we see today.

IBM had to address the limitation imposed by the communication lines and networking hardware, and developed a robust protocol that would guarantee the integrity of the messages.

What you need to know about SNA today

During the 20-year period when SNA was the primary networking method, many CICS and IMS application programs were developed and put in place. The application programming interface (API) of these application programs is heavily dependent on the underlying protocol, SNA.

It is apparent that TCP/IP is the dominant networking protocol now and for the foreseeable future. Today, new applications use state-of-the-art programming techniques, like Java and HTTP, but it will take many years until all SNA applications disappear. Why is that so?

A networking application is dependent on the communication protocol it uses. Every protocol provides an application programming interface (API). TCP/IP's API is called socket programming and SNA has its own API. Migrating a networking application from one protocol to another (that is, from SNA to TCP/IP) requires replacing the calls to the API. Business mangers are reluctant to invest in protocol conversion only for the sake of changing the underlying protocol without introducing new functions and improvements.

More importantly, in the past 30 years businesses have invested a tremendous amount of labor and money in developing SNA applications. It is estimated that the investment made in CICS and IMS applications is in the range of 20 trillion US dollars. Considering the investments in SNA applications, these programs will be used for many years. To recode these applications as TCP socket applications is often impractical and cost-prohibitive. Besides, alternatives exist.

IBM introduced new technologies to help businesses preserve the investment in SNA and use IP as the protocol for connecting SNA computers. The technology is known as SNA/IP ("SNA over IP"). The two endpoints, the SNA application in the mainframe and the SNA application in the remote location (branch, store), remain unchanged, thereby preserving the investment in SNA.

Because SNA applications will exist for years to come, someone has to care for SNA definitions, problem determination, recovery, business continuity procedures, and many other tasks. These tasks are the responsibility of the mainframe networking systems programmer who needs to know in depth the architecture and how to implement SNA on various hardware and software platforms.