November 19, 2014 | Written by: Jeff L. Smith
Share this post:
One of the more popular TV fads today involves shows where old classic cars are modernized. The mechanics update the engines, tires and brakes and make the cars go faster, but they don’t change the way the owner drives the car.
Similarly, Systems Network Architecture (SNA) applications are transactional applications that can be considered “classic.” These applications are often critical to a business because they are an integral part of an overall business process. One cannot make changes to existing SNA applications wWelcome, Shru CNithout collaborating with mainframe-based business processes. Such collaboration can be expensive.
I have been able to migrate existing SNA applications to modern cloud network infrastructures without any modification to the SNA applications. This means that an end point (automatic teller machine, workstation or server) can access the mainframe host application using TCP/IP without any code changes.
The SNA modernization strategy for distributed node access is described in this IBM Redbooks publication.
This strategy describes how to migrate applications to a cloud using a remote application programming interface (RAPI) client-server implementation. The benefits of migrating SNA applications to a cloud type infrastructure are centralization of SNA support, reduced costs and new access to application performance measures.
Centralization of SNA support
Expertise in SNA is waning in the marketplace. SNA predates the Internet, and many of the SNA host-based applications are still in use, but with diminishing developers and less support available to make significant changes. This means that SNA applications that are distributed across a company’s infrastructure can be expensive to support in order to provide SNA in branch environments.
Using a RAPI implementation to replace the direct SNA access to the host with TCP/IP reduces the footprint of SNA in client machines. Existing SNA protocol stacks require 100 to 1,000 parameters to manage all the logical units that SNA uses for application connections. A RAPI configuration requires no more than three or four parameters per client. This also means that administrators can consolidate their focus on data center servers so that implementation of SNA can be more focused.
Reducing the cost of SNA implementation
When SNA support is licensed on a distributed model, the branches and remote installations will require a license that is workstation or server based. By consolidating SNA to a central data center, the licensing can be done on a per processor or concurrent user basis. This often reduces the initial outlay to between 30 and 40 percent of an existing implementation.
Further savings are realized in the reduced CPU utilization on the mainframe host application because it does not need hundreds or thousands of connections, just a few from the local SNA cloud servers. This will also reduce the overhead storage requirements on the mainframe. See the savings in SNA and networking overhead in the following diagrams:
New access to performance measures
When I have been engaged in migrating the network implementation from an established SNA connection to a RAPI implementation, the existing environment has provided little to no information about how busy and predictive the SNA application flow currently is. For instance, an insurance agent may have seven different SNA back end applications that provide the coverage and support for the clients serviced by the branch office. In existing flows, the different application accesses cannot be separated such that the overall performance for a particular application can be deciphered.
Using an SNA cloudlike infrastructure and centralizing the SNA access to a domain of servers provides a lot of detail about every application flow. This information can be gathered to plan for peaks, trends and other requirements such that administrators and architects of the network can get granular insight into how the applications are being used.
Migration can be easy
The technical aspects of taking an existing SNA application infrastructure and migrating to a RAPI implementation can be done easily. In my experience, it has taken no more than two or three hours to install, configure and connect the SNA cloud servers to the back end host systems. Since the RAPI is a thin client with only three or four parameters, the client can be installed and configured in one script, often in one statement in a script. Applications are not impacted in many cases.
Migrating SNA applications to a cloud implementation is very beneficial and not expensive to carry out. If you like seeing classic things become modernized, chime in with a comment below or contact me on Twitter @jefsmith5221.