Operating Systems

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.

6 Pages