Jan 1 ’04

Jurassic Networking: SNA Applications in an IP World

by Editor in z/Journal

Like the mainframe, many people have predicted the death of SNA networking. This article examines the current state of SNA networking and applications, and explores the reasons why many enterprises choose to maintain their investment in SNA applications. We also examine some alternatives for transporting your SNA data across an IP network and help you determine the best way to do this.

Not long ago, people were saying the mainframe was dead. Along with the mainframe is a perception that SNA is also dying. Compound these feelings with IBM announcing the end of marketing for its SNA networking hardware, and it is natural to assume that SNA is going away. In actuality, after digging deep into the inner-workings of enterprises around the world, IT archeologists have found that SNA applications are a critical piece of the core processing for many businesses. Given the importance of these applications, it’s natural to wonder what you should do with your SNA applications.

At the same time, you might be dealing with a number of other issues. For example, you may be trying to simplify your infrastructures. After all, supporting two network infrastructures is expensive in terms of equipment, connectivity, and management. A common business problem today is that solutions implemented by different organizations within an enterprise have created overly complicated, redundant, and nearly unmanageable collections of hardware and software. Infrastructure simplification initiatives are needed to get control of these environments.

Perhaps you are also looking at branch transformation projects to build new solutions, which can help improve end-user productivity or deliver new business offerings. Before you decide whether to keep your existing SNA applications or to build new solutions, you need to ask the following questions:


Linux has become an important platform to help solve some of these problems. IBM’s recently announced Communications Server for Linux on zSeries enables SNA support on the open Linux platform. This opens up possibilities such as consolidating large numbers of branch office servers onto one machine or a small number of machines in the data center. The resulting savings in hardware, software, and management expense can then be used to invest in developing new business applications.


The question facing many enterprises is, “Should we rewrite our SNA applications to IP or maintain the investment we’ve already made?” Most enterprises, especially those whose business has grown with and is integrated with their applications, choose to keep much of their existing investment. The following section examines items to consider when deciding to maintain or rewrite.


More than 90 percent of the world’s corporate data resides on z/OS-resident SNA applications. Today, major corporations find themselves relying on the same SNA applications that have driven their business for more than 20 years. The business logic incorporated in these applications is as sound today as it has ever been, but the infrastructure supporting those applications has many IT managers tossing and turning at night, wondering how they can maintain their application investment while expanding their networking capabilities with the latest technology.

SNA as a networking protocol is rapidly approaching its end of life, but this fact in no way lessens the importance or viability of these SNA applications or the SNA application programming interfaces (APIs) to which they are written. It also does not extend the elapsed time since Year/2000 when many large investment decisions were made and the technology was expected to be productive for at least a decade. IBM’s Communications Server’s Enterprise Extender support provides the function necessary to transport SNA application flows over IP networks in a highly efficient and effective way. Real consideration must also be given to the placement of your SNA endpoints; alternatives include the branch office, regional center, or data center. We will discuss these topics later in more detail.

The decision is whether or not to scrap these SNA applications that have served so long and so well and develop replacements on IP. During these times of budget tightening and consolidation, it is not a pleasant thought to have to redevelop applications that are already serving reliably in your network. Yet, the aging SNA infrastructure and the need to maintain networking infrastructure currency would appear to force this consideration. Additionally, since parallel SNA and IP networks have proved to be expensive to maintain, it is necessary to consider alternatives for transporting SNA data across your IP networks. These considerations become especially important in light of the eventual end of service for front-end processor (FEP)- based solutions, such as the IBM 3745 or Cisco CIP.

Rewriting an application is a major undertaking, but the considerations surrounding that application may be far more involved and costly in terms of both time and money. The development of any large application is an expensive proposition, but when that application is intertwined with the corporate processes and procedures, that expense can rapidly mushroom. Many existing SNA applications grew with the business they serve, and the business processes and procedures were developed based on the information provided by the applications. Ensuring that no facet of your current business logic is neglected is very challenging. That, coupled with the development of a new application that will ensure the continued interoperation with all the remote operation centers and branches in your corporate network, as well as those of your business partners and suppliers, is indeed a daunting task. The testing and deployment challenges associated with such an undertaking would merit a significant and equally expensive prototyping or staged deployment effort, contributing to the cost of developing replacement applications.

Rewriting an SNA application to IP requires careful planning and an understanding of the differences in the two environments. Many of these applications exploited features such as accounting, billing, diagnostics, and class of service provided with the SNA product set. When moving the application to IP, this functionality must be replaced by multiple offerings. These offerings require coordination on top of IP, and this extends the scope and cost of the redevelopment effort. In some cases, the necessary SNA function does not even exist on IP.

An obvious and significant cost of developing a new application is thorough testing. This is a major financial consideration, but more important and perhaps frightening, is the potential disruption of business operations during early deployment. Time will permit new applications to become as stable and reliable as the SNA applications are today, but the cost over this period is very difficult to estimate, especially when a minute of downtime can cost a corporation more than the total estimate of the development cost.

If the technical and financial requirements of redeveloping SNA applications on IP have been met, the next set of issues to be considered are those that deal more directly with the employees who manage, maintain, and use these new applications.


SNA-based management procedures, which enable operations to quickly recognize a problem has occurred, must be replaced with IP management tools and processes. Many such tools are available today, but they are usually provided as a separate package, which requires routine maintenance and a new set of skills. This requires retraining the operations staff in addition to the cost of the new management product. The cost of the product and development of the new management applications may seem low when compared to the cost of retraining corporate employees who are welltrained on the existing SNA management tools, but will have to start anew with the new tools.

Preparing the operations staff and tools is a significant investment, but that expense pales in comparison to the costs associated with having to change the processes and procedures used by the majority of the company’s employees. Since many such processes and procedures are tied directly to the logs and features available with SNA, this is a very real consideration. Of course, the new applications can be developed to closely imitate their predecessors so that the non-computerized processes and procedures of the corporation do not need to change. But then, you might ask, what has been accomplished by the costly redevelopment of the applications?

If the answer to this question is simply that the applications are now resident on IP networks, and therefore are enabled to take advantage of all the latest networking technology, then there is certainly a better way to accomplish that. If the Jurassic applications are providing the business logic needed to operate and grow your business, then IBM’s Communications Server on z/OS and Linux on zSeries can provide the needed networking support to connect them to your IP networks. This consolidation will not only minimize networking costs but also help avoid new application development and keep IT managers from having to retrain their workforce or losing their systems during an early deployment.

The decision to be made is a business decision, not a technical decision. Is it more economical to develop and test new applications, replace all the peripheral processes and procedures, and retrain the corporate staff or to simply permit Communications Server to securely and reliably transport your tried-and-trusted SNA applications over your IP network? The answer seems clear. It becomes even clearer when you recognize that your business applications are fully enabled to exploit the most current IP networking technology. The best of both situations can be realized; that is, the stable, reliable and time-tested business logic exploiting the latest IP networking technology and sharing the IP infrastructure with Web-based offerings.

Sleep better tonight! There is no need to scrap your applications to move your networking to the latest IP technology. At this point, it should be clear that there is ample reason for you to strongly consider maintaining your applications and consolidate and simplify your network infrastructure. So, now let’s take a look at how to do this.


If you decide to keep your SNA application, what’s the best way to transport the data? Before the rise of IP as a transport technology, this was a fairly simple decision. You would use Network Control Program (NCP) running on an FEP to build your network. The FEP was connected to the mainframe via ESCON channels and the end users via a token-ring LAN. TCP/IP started changing this by allowing new alternatives. Over the years, many transport protocols have been delivered. Space does not permit us to discuss them all, so instead, we will focus on two that are significant today: data link switching (DLSw) and Enterprise Extender (EE). We will also examine mainframe network connectivity choices.

For many years, the high speed and reliability of ESCON made it an important piece of mainframe-based networking. However, high speed is relative. In the early days of SNA, 9600 baud links were considered high speed. This led to the development of concise data flows. The movement toward Web services and on demand computing requires significantly larger bandwidth. The ESCON connections that were once more than ample for host access may no longer cut it. In order to meet this demand for increased bandwidth, IBM developed the Open System Adapter Express (OSA Express or OSA-E). OSA-E is available in a variety of protocols; the most common is gigabit Ethernet. This adapter provides significantly more bandwidth and is optimized for network traffic. The chart in Figure 1 provides a quick comparison between ESCON and OSA-E bandwidth.

The next consideration is transporting the data across the network. Today, many networks are a hybrid of FEPbased SNA and router-based TCP/IP. The FEP provides host-to-network connectivity and DLSw transports the data across the TCP/IP network. This technology has worked well, but does create some issues. FEP-to-host connectivity uses ESCON. This means any traffic flowing across this part of the network cannot utilize the high-bandwidth capabilities of OSA-E. Additionally, since IBM has announced end of marketing for the 3745, the FEP solution has a limited life.

For years, DLSw has been a popular method of transporting SNA traffic across TCP/IP networks. However, DLSw has limitations in the areas of scalability, performance, and availability. DLSw encapsulates SNA traffic and then transports it through the network via TCP/IP. Performing this encapsulation is processor-intensive, often resulting in banks of DLSw routers in the data center to support all the downstream users. Since these routers are so busy performing encapsulation, they are usually dedicated to this purpose. An entirely different set of switches and routers is needed to actually handle the TCP/IP traffic. When the encapsulated SNA data is sent across the TCP/IP network, it is usually done with one priority. This means the SNA class of service is lost, resulting in mixing batch and interactive traffic. DLSw also introduces into the network single points of failure. If one of the endpoint DLSw routers fails, all the sessions through that router fail. This is similar to the limitations of the subarea SNA VR outages.

EE is an alternative technology for transporting SNA across an IP network. EE utilizes advanced peer-to-peer networking (APPN), high-performance routing (HPR) to send SNA data across an IP network. The data is encapsulated in user datagram protocol (UDP) packets for efficient IP routing. If a packet is lost, the EE endpoint will handle the retransmission. Embraced by many vendors, including IBM and Cisco, EE has become a great choice for consolidating your network to a single IP infrastructure. If you decide to use EE to transport your SNA data, which will simplify your network by removing SNA hardware such as FEPs and DLSw routers, the next question you need to consider is on what platform(s) should you implement EE? Since EE is included as part of Communications Server for z/OS and Linux on zSeries, the mainframe is an obvious choice, allowing you to benefit from the high-speed connectivity of OSA-E.

Deciding which platform to place at the other end of the EE connection is a bit more complicated. For connections between mainframes, the solution is obvious—on the other mainframe. In the distributed environment, two solutions are widely used: IBM Communications Server (available on Windows, AIX, and Linux) or PCOMM, and Cisco SNA Switch (SNASw). These endpoints can be placed in the data center, in a regional center, or even in the branch office. In a later section, we will focus on the actual location. For now, let’s look at some of the things to consider when choosing a specific platform.


Cisco’s SNASw provides EE on a router, which is a great choice for many situations. Many distributed SNA solutions are implemented using an SNA product that does not support EE. Connecting these users through an SNASw router in a branch office allows the users to benefit from the availability and performance capabilities of EE.

IBM’s Communications Server and PCOMM products provide native EE support. SNA solutions implemented using one of these products will benefit from end-to-end EE support, resulting in significantly improved availability and a greatly simplified network. The new Communications Server for Linux on zSeries allows you to consolidate SNA branch office solutions onto a single mainframe.

SNA support for distributed users can be handled via EE on SNASw or IBM’s Communications Server, removing the need for FEPs to handle the distributed workload. This often results in only needing the FEP to handle SNA network interconnect (SNI), which provides SNA connectivity between enterprises. VTAM and NCP work together to establish SNI network boundaries, which allow enterprises to connect, but also provide network isolation. APPN has a function called Extended Border Node, which is an excellent replacement for SNI, and is being widely used.


APPN has been available for many years now; why would someone not use it? Most of the time the answer falls into one of two categories.

The first answer is “if it’s not broken, don’t fix it.” A traditional subarea net work has worked fine for many enterprises. However, even though the subarea network is not “broken,” there are a number of compelling reasons why it is no longer suitable for many enterprises. These reasons include the expense of maintaining separate IP and SNA networks, the need to improve availability, and the increasing bandwidth required as a result of consolidations and changing workloads.

The second answer is “fear of the unknown.” People who have supported mainframe networks for many years are comfortable with the definitions for SNI connections. The thought of throwing these away and having to deal with new, unfamiliar definitions makes them uncomfortable. Perhaps they have heard bad things from other people who tried to implement APPN and encountered many problems. We can tell you from experience that these fears are real. Migrating from subarea-based SNA to APPN is a significant change. The good news is many people have made this migration and are very happy they did. There is now a large base of experience on which to draw to help make your migration successful.


You can put SNA in the data center, regional centers, or even the branch office. What are some of the things to consider when making this decision? How do you plan to replace those OS/2 servers that have worked so well for all these years?

For years, people had SNA clients, in the form of something like a 3270 “green screen,” on their desktops. Over time, the dumb terminals were replaced with PCs. However, even though the users had a PC, they still used software that was basically just an emulated “green screen.” The next trend was to utilize screen-scraping solutions to present data in a more user-friendly manner. Add to this Web browser-based clients, which were able to provide the “green screen,” or a custom presentation to a light client, and the result is that it is now common for the end-user device to be an IP-only client that interfaces to a server. The purpose of the server is to obtain the necessary information from SNA applications and present it to the end user via IP. These solutions have been covered extensively in other articles. Instead of delving into them here, let’s focus instead on where these servers can be placed.

Traditionally, these servers have often been placed near the end users, perhaps in the branch office. This is often done when the server performs additional work for the branch office users. This solution usually provides good service to the end users, while introducing maintenance challenges in the remote locations.

These servers are sometimes consolidated into regional data centers. When this is done, the servers can be physically moved to the region or consolidated onto one server. The size of the end-user population, number of branches, etc. will dictate whether these regional centers are needed long-term. The servers can also be “pulled back” all the way to the data center. As with the regional center, this could be just a physical move, or it could include server consolidation.

Consolidating the work onto fewer machines, either at a regional center or the data center, results in a solution that is easier to maintain and has a lower total cost of ownership.

Figure 2 summarizes the considerations for placing the SNA function in the branch, region, or data center.


Where SNA is going totally depends on your vantage point. The SNA networking infrastructure served us very well when telecommunications lines were slow, expensive, and their reliability was measured with a few 9s. Today, that is simply no longer the case in most of the world. SNA as a transport has outlived its fundamental usefulness and the infrastructure products from IBM and other vendors that provide that transport are destined for the great scrap crusher in the sky.

IP technology is well-suited for reliable, high-speed communications lines. Indeed, IP network technology is ubiquitous and steadily improving through contributions from the open source community. IBM, like other vendors, has for some time now focused on IP as its network transport. Does all this mean SNA is dead? On the contrary, SNA applications are still thriving, but they can now exploit a network transport appropriate for today’s communications technology—one that will grow as that technology grows. As we briefly described earlier in this article, EE enables your SNA applications to fully exploit the latest IP technology transport. EE has been available for some time on z/OS, but is now available on Linux on zSeries.

Indeed, technology on Linux is growing even faster than IP today and is certainly far outstripping proprietary systems. It is exploding both in terms of functionality and acceptance. The key is to bring customers the best of both the z/OS world and the Linux world together in one box—that is, enable z/OS-resident SNA applications to take full advantage of IP networking technology. Likewise, SNA and IP applications on Linux are enabled to exploit many of the reliability and security features today reserved only for the z/OS environment.

Given that the SNA infrastructure is fading into the sunset, the EE support on Linux permits the business logic in your SNA applications to continue to deliver for you. Your application data is transported by the latest IP technology (they grow with it) and the front-end to the z/OS resident applications is the hottest operating system in the marketplace, Linux. Consider the difference in skills requirements. Every college student entering the business world is well-versed in Linux, while the skills on SNA transport products is graying fast and certainly not readily available. Linux, along with z/OS, will carry your SNA applications into the future.

The SNA infrastructure products clearly are in the winter of their lives, but those golden SNA applications are as valuable and vital as they were when they were first deployed. In fact, they may be even more important now since most businesses grew up around them and based many of their business processes and procedures on them. They will live on and even grow on their newfound IP transport until the business logic they execute is no longer required. And that could be a very long time!

Just when you thought all the problems were solved, you realized that this solution is built on EE or as it is often called, HPR/IP (high-performance routing on the IP transport). EE is the strategic solution for enabling the transport of SNA traffic over an IP transport and it rides squarely on native IP, enjoying all the current and future benefits of IP network transports. EE will continue to ensure that SNA applications can be served by state-of-the-art IP networking technology. All that being true, we recognize that there is a contingent of customers who are, for one reason or another, still using the now very stable Subarea SNA transport.

So, you might ask, what are you going to do for my SNA Subarea transport? I still use SNA Network Interconnect and EE cannot help me with that!

Although it is highly unlikely that any vendor will ever again provide all the function that resides in the NCP on the 3745/3746 FEPs, the Linux platform could assume the SNI function, enabling Subarea customers to retire their SNA infrastructure and begin using an IP network to talk to those who will not move. Of course, it is unreasonable to expect all those who have not moved to HPR over the extended period of its life would decide in unison to move! In fact, it is even unreasonable for one business to expect that all its business partners will migrate in unison. Clearly, any solution to such problems should enable each customer to make an independent decision. That is, each can decide to migrate independent of the decisions of its business partners and providers. Calm your fears, the end of life of SNA infrastructure will not cause you to lose your SNA application investment. Rest assured that your investment will be enabled on IP well before that infrastructure goes out of service.

Of course, IBM does not provide the IP networking infrastructure today and therefore joint solutions with our major network equipment vendor partners are necessary to ensure that this EE offering not only supports APPN customers, but that there is an EE variation, which will enable Subarea SNI customers to enjoy the benefits of IP interconnectivity. EE function will expand to enable the Subarea segment of customers to consolidate to an IP network and reap the financial benefits of a single network for both SNA and IP applications.

SNA was created at a time when networks were, at best, chaos. The SNA network infrastructure was designed to address the limits of then current link transports, and it was the best transport in the world for that time. Alas, its time has passed, and with it goes the SNA network infrastructure. However, the APIs and middleware on which you built your SNA applications are as vital today as ever. Equally important is the fact that your business processes and procedures, which grew up with and are dependent upon your SNA applications, remain intact. The removal of SNA network infrastructure results in a significant network consolidation to a single IP infrastructure and reduces your overall cost of networking support. Consider the before and after network diagram shown in Figure 3; specifically, note how much more streamlined the after network diagram is than its predecessor. Also, consider the fact that only one network infrastructure management skill is now required instead of the current two. Moreover, as IP technology continues to improve, your SNA applications will continue to benefit.

In addition, this new Linux offering will enable new applications to be developed in a highly robust application development environment along with other software products, allowing Linux applications to enjoy some of the most demanded attributes of the z/OS platform, including security using RACF. Other possibilities include the reliability of z/OS and many of the features that the IT community rely on to manage their z/OS systems and wish they had available on their Linux systems.

With the combined strength of Linux and z/OS, applications will enjoy the very latest in IP and policy-based technology, and the Linux applications on zSeries will enjoy the very best security in the world as well as many of the system tools that the IT community has grown accustomed to and are not currently available on the base Linux platform.

It is amazing how well you can rest when you know that your applications are not only golden to you and your business but also to your software provider. Who says dinosaurs are extinct? Z