There aren't many legacy computing technologies that have stood the test of time.
But Systems Network Architecture (SNA) is unique. The technology, developed in the early 1970s by IBM Corp. for large mainframe customers who were looking to automate transaction processing, continues to be a framework for important business applications for large corporations. SNA's secure set of functionality and reliability makes it the epitome of secure networking, with its ability to expect and identify literally everything that can possibly go awry and ensure that SNA application processes get to their predetermined destinations.
The SNA credo is "anything that can go wrong will go wrong." It means that certain types of expected errors, such as telephone line or modem failures, are handled automatically in an SNA environment, while other unexpected failures, such as problems with software or configuration tables, are isolated and logged by the network, and trigger alerts to operations staff for their analysis and response. SNA is a safe and secure environment -- a network manager's dream.
But is it technological excellence or huge corporate investment of IBM customers that keeps SNA alive? The truth may be that both sides of this equation are equally responsible.
"I don't think (SNA) will be replaced, only because there are trillions of dollars of application investment in it," says Jim Goethals, an enterprise solutions product marketing specialist for IBM Corp. in Research Triangle Park, North Carolina. "We continue to make enhancements to the architecture. I would say we're currently in fine-tuning mode with the technology.
"The use of the architecture for new applications is really a customer or vendor choice. We do see growth in SNA, but not at the level of what we see TCP/IP growth at this point. But there is still growth."
The pervasive trail being blazed by TCP/IP throughout literally every network in the works has brought SNA to a crossroad. SNA network infrastructures are being transitioned. Frankly, nobody builds out an SNA network any more and everybody seems to want to move to much more versatile IP, especially for the client side of things.
Originally, SNA networks were built out of expensive, dedicated switching minicomputers all managed by a central mainframe. The dedicated minicomputers ran a special system called Network Control Program (NCP), which managed communications on behalf of all the terminals, workstations and, these days, PCs connected to it. In a banking network, for example, the NCP might manage all the terminals and machines in branch offices in a particular metropolitan area. Traffic is routed between the NCP machines and eventually into the central mainframe.
The rapid growth in minicomputers, workstations and personal computers ultimately forced IBM to develop a second kind of SNA. Customers were building networks using AS/400 minicomputers that had no mainframe to provide control. This new SNA is called Advanced Peer-to-Peer Networking (APPN). APPN and sub-area SNA have entirely different strategies for routing and network management, but their key common characteristic is support for SNA applications or devices using the Advanced Program-to-Program Communications (APPC) LU 6.2 protocol.
It is these applications that are key to understanding the SNA picture these days. Many users want to keep SNA applications but not the relatively limited and slow-connection SNA network environments of green-screen 3270 terminals and mainframes. Through products such as TN3270 gateways -- devices that speak TCP/IP on one side and establish SNA connections on the other -- business are breaking out of the box, as it were. TN3270 gateways let users link newer TCP/IP-based networks with vital legacy SNA applications.
Petro Canada use IBM's CICS transaction processing system for certain credit card application functions and wants to Web-enable its system for large customers who want to do their own credit card updates.
"Our business logic is still on the mainframe on CICS," said Wayne Ferguson, a senior technical specialist for Petro Canada in Toronto. "CICS does run under Unix so we hope to port the CICS application down to Unix and we're not sure what interface we'll use to go in between. It could eventually be a Java interface but right now it's just an SNA link.
"SNA is a more secure technology," he added. "It seems to re-establish links much better than TCP/IP. We tried using MQSeries (an IBM transaction processing management system) with TCP/IP, but the system wasn't as stable as it was with SNA. I'm not sure that TCP/IP is there for that kind of stuff yet. That's really one of the problems with TCP/IP."
IP technology is fundamentally different from SNA. Described as a connectionless technology, IP routes individual packets of data based on an address number that identifies the destination machine, rather than first establishing a direct connection or "session" to that device. IP networks have no view of a session.
In contrast, SNA clients and servers cannot exchange messages unless they first establish a session. In a sub-area network, the mainframe gets involved in creating every session. There are control blocks describing the session in the NCP to which the client talks and the NCP to which the server talks. Intermediate NCPs have no control blocks for the session. In APPN SNA, there are control blocks for the session in all of the intermediate nodes through which the message passes.
Every design has advantages and limitations. The IP connectionless model is designed to work well in experimental networks built out of spare parts and lab computers. But errors in an IP network often go unreported and uncorrected, because the intermediate equipment reroutes subsequent messages through a different path.
The SNA design is a model for building reliable commercial networks out of dedicated, centrally managed devices. SNA, however, requires a technically trained central staff able to respond to problems as the network equipment reports them.
Raymond Industrial, a heavy equipment manufacturer in Brantford, Ontario, is looking to migrate away from SNA technology on the client side. But, according to network administrator Ed Garnham, SNA won't be completely eliminated.
"SNA is much more secure than TCP/IP and that's the primary reason why we use it," he said, noting that his corporate network has SNA applications tied to AS/400 systems in an environment that features primarily IBM client PCs.
"What we've done for our PCs is use Microsoft SNA Server as a gateway and that eliminates the need to run SNA on the client," Garnham added. "The majority of the SNA traffic here is only between the SNA Server and the AS/400 and we're migrating to TCP/IP (on the client side)."
Such a mix and match patchwork of TCP/IP and SNA is the typical look of many former true blue IBM shops these days.
Steve Drake, an analyst with International Data Corp. in Framingham, Massachusetts, said there are some SNA-only networks today, but the more common scenario is a whole range of mixed SNA and other networking technologies -- especially IP.
"Banks are a good example. A bank might be running its automated banking machine network through SNA. It's been there for a while and it's very secure and predictable, so they keep it.
"They may keep that network on SNA while the rest of the bank might be on IP-only. Another scenario might be IP everywhere except for the data center, where there's SNA."
Drake called IP a driving force for future IBM technology development around SNA and said many companies don't want their mainframe resources isolated from IP-based networks.
IBM's Goethals agrees IP is an important technology. He cites research which states that approximately 24 per cent of desktops are IP-based, expected to rise to 80 per cent by 2001. That said, however, IP can't do what SNA can because network managers give up a number of things when they run SNA over TCP/IP, including the ability to prioritize their SNA traffic, he explained.
"On pure SNA, because it is connection-oriented, you can run various streams of traffic over a number of circuits and choose those that get the best service. You can't do that over IP."
IP, being connectionless technology, places all traffic in an outbound streaming queue within a router. If the traffic is sent on and received by another router in the network and the priority scheme in that router isn't set up in the exact same way, then the entire priority system breaks down.
"In an SNA or APPN network, a connection is established through the network and a path is built in such a way that you'll get a guaranteed level of service through that path."
Goethals said he believes IP will really take hold as businesses look to conduct more commerce over the Internet, using Web sites as customer connection points. Java, HTML and HTTP are opening up new ways to invent and use technology to deliver different kinds of services, he said.
"There's a lot of investment going into e-business storefront building and that's driving huge growth in TCP/IP applications.
"You see mixes of everything," he said. "The SNA applications are a given ... they're going to be there. But what you're seeing is people, at various points in their (business) evolution, running two separate networks. You see people converging onto an IP backbone. You see mixes and matches. It comes down to : if an application requires a certain level of service or a certain level of prioritization, it will stay on the SNA side vs. IP because IP can't provide some of the same environmentals that SNA can.
"People are moving towards an IP infrastructure with hybrid ways to integrate the SNA flows at the same time."
Still there remain pure SNA networks for the very reasons why they were implemented in the first place.
"We do have customers who have pure SNA networks," Goethals said. "Those are customers who need guaranteed service levels that are critical to their business.
"You don't see Wall Street (investment brokerages) sending billion-dollar wire transfers across the ocean on IP. Those are SNA connections and there's a reason for that. It's reliable, dependable and users know the stuff gets from one point to another."
(McLean is research manager, network support and integration services, at IDC Canada Ltd. in Toronto.)