In-Depth

The Internet Meets the Mainframe: Management of 21st Century Mainframe-Centric Networks

• 09/01/1998

The mainframe continues to be the source of debate and discussion among analysts and corporate IT organizations. Exactly what constitutes a "mainframe" was the entire subject of an analyst research report in the past year. Other questions being considered are: "Should we centralize/decentralize? Should we replace it with a client/server system? Relegate it to a large data server? Get rid of it? Use it to connect our business to the Internet?" Now, there’s an idea!

The discussions continue. In the meantime, although most mainframe components remain unchanged, their names have been changed to make them more attractive. A mainframe is now an "enterprise-server," MVS becomes "OS/390," and "eNetwork Communications Server for OS/390" replaces TCP/IP for MVS, VTAM and Anynet.

One area that is changing constantly – to adapt to the challenges of 21st-century applications - is the underlying network infrastructure. Most organizations have begun to migrate from pure SNA environments to some combination of TCP/IP and SNA - which has also been dubbed "eNetwork" by IBM. Some organizations have resolved to eliminate SNA altogether. The difference between eNetworks and other fads of the past, is that organizations are actually finding fast and tangible results in employing this new hybrid network. MCI recently stated an expected three-year ROI of $16M with the majority of the savings coming strictly from hardware maintenance.

At the bottom of all this migration is a single theme – accessing critical data and applications residing on an enterprise-server (or "mainframe") from an Internet-based desktop, or "Webtop." Understanding the technology is critical to making the right decisions for your business. What does it mean to "get rid of SNA?" What does this new network look like? What are the risks? How does an organization manage the migration while maintaining service?

If you’re like most organizations, you began with a pure SNA network and added access via a routed network to accommodate a branch office within your organization. Consolidations, takeovers and out-sourcing were trends in the last five years that encouraged this. In early implementations, the changes were within the IP network domain and so it wasn’t a great concern from a mainframe management perspective.

IT organizations soon began to make a proactive choice to move to TCP/IP routed networks as the wide area network protocol, replacing very reliable SNA networks. Desktop TN3270 emulation software took hold as a way to cheaply provide remote access to mission-critical applications operating under the SNA protocol. In fact, TN3270 terminal access is still usually the first application deployed under the new network model.

In this scheme, the applications still run under SNA, only the way a user accesses them has changed. To completely remove SNA requires actual conversion of the legacy applications. This type of retooling is expensive, unless work is already being done for other purposes, such as Year 2000 compliance. Most organizations choose to leave these applications in SNA format, instead putting their efforts into providing WEB-based interfaces when required.

Since traditional SNA routed networks have been measured at between 99.8 percent and 99.9 percent reliable, why are many businesses moving away from this technology? SNA’s high reliability comes with a high equipment cost (FEPs and lines, for example) and a slower speed (64Kb) compared with newer technologies, such as ATM and Frame Relay.

But probably the most dooming factor is SNA’s inability to interface effectively with corporate i*nets, which are more often being used as a critical service point for communications and business applications within today’s data centers. Just think of the number of people Federal Express or UPS would need to hire to replace its World-Wide Web (WWW) package look-up service. Imagine the competitive disadvantage of a company that doesn’t provide a corporate home page by the year 2000.

With these new applications and users being networked, a new concern arises. The fact that SNA is a proprietary, single vendor solution contributes much to its high reliability rating. TCP/IP, on the other hand, is an open, many vendor solution. Lost packets, hung routers, network performance slowdowns, translation errors and other such problems are the result of this varied environment. Thus, a reliability rating of 93 percent is generally the best that can consistently be obtained.

If you ask a network administrator how reliable their system is, they usually perceive it to be much closer to their old SNA network. An outsourcer I recently worked with stated that they could achieve 99 percent plus reliability on their TCP/IP routed network, while at the same time admitting that they have average outages of more than 30 minutes a month! Stories like this are common. In terms of network management, reliability is generally equated with being able to access the application, but that obviously didn’t match my customer’s thinking. Why?

I think the answer is twofold. First, new infrastructure technologies, such as Frame Relay and ATM have increased the speed of communications by up to 25X. This means that an outage doesn’t impact end users’ perception of reliability, since total productivity isn’t affected. Second, by nature, IP-based networks tend to be de-centralized and department-specific so that each outage actually affects fewer end users. In this outsourcer’s case, only about 15 end users were affected in their most recent two-hour outage.

Serious router vendors like Cisco are moving quickly to improve the reliability of individual components in the IP infrastructure. In the meantime, network administrators perceive that they are providing adequate service, but end users are still not happy with the results.

The most common method of connecting the enterprise-server to an IP network is by implementing a "mainframe stack" (i.e., software, which runs on the mainframe and provides TCP/IP protocol functions, much like a router in the network). There are two primary choices in the mainframe stack business – IBM and Interlink Computer Sciences, Inc.

IBM’s flavors of the stack are TCP/IP for MVS, versions 3.1 and 3.2 which focused on OS/390 IP traffic, and TCP/IP for MVS version 3.3 which contains enhanced functions targeted at running UNIX applications on the mainframe. Under competitive pressure, IBM re-architected the stack software to improve performance, and integrated the mainframe and UNIX features into a single offering which is now called eNetwork Communications Server for OS/390 v2r5. Interlink’s alternative to IBM’s implementation is called TCPaccess.

Other solutions are available which can integrate either loosely or tightly with the enterprise server. For example, Cisco Systems, Inc., provides an option for their series 7200 and 7500 routers called a Channel Port Adapter (CPA) and Channel Interface Processor (CIP), respectively. The CPA/CIP card can be configured, among other things, to handle all TN3270 traffic through a server residing on the router instead of the mainframe. This takes CPU load off the mainframe itself, and allows for incremental increases in TN3270e traffic by adding additional cards. In this configuration, the mainframe talks SNA to the router, but the router talks TCP/IP to the network.

In turn, IBM has announced an outboard TN3270e capability for its 2216 Nways processor that works in much the same way. This support was announced in November 1997, and should be delivered before the end of 1998.

You can also choose from hardware and software "gateway" solutions that provide full or partial SNA gateway functionality – everything from printing to TN3270. A brief subset is provided in Table 1. Competition is keen in this area, and vendors are making investments in break-through technologies, so it pays to do a careful vendor and feature analysis before making a purchase for your network. A multi-vendor, mixed environment can make for an operational smorgasbord. Nonetheless, many have additional features that are appealing, such as a WEB interface or enhanced security.

The challenge in effectively managing outboard sessions is being able to access information within the gateway itself, and correlate this with the SNA side of the connection. This is a problem because IP devices use SNMP as a communication protocol, but the OS/390 platform does not digest SNMP information very well. And with such non-SNA hardware becoming a crucial component of enterprise applications, it is also important to understand the relationship between a device and the applications it services. A northeastern state agency, for example, uses FTPs over particular paths to communicate information on missing children to local authorities. If you were the Help Desk manager responsible for that failure, wouldn’t you want to know if there was a failure in the route used by this critical and timely transfer? Wouldn’t you want to know if there could be a delay in the delivery of that information?

Although TN3270 is the number one use of TCP/IP in mainframe networks, organizations may have other requirements for data sharing and transport across the enterprise. File transfer protocols, as already mentioned, are another common application. The drive of the i*net and the inherent capabilities of the eNetwork, make a great platform for a new breed of applications, such as enterprise-server based e-mail systems, Web servers, messaging middleware and firewalls.

Putting it all together, you get a hybrid network. Old and new technologies and protocols exist side-by-side and will for some time, according to the Gartner Group and other analyst organizations.

How do you manage response time and availability, while planning for the future growth of all these types of transactions? TCP/IP problems are notoriously difficult to detect because understanding reliability problems requires a correlation of information from a number of sources, including SNMP, ICMP, the OS/390 system, outboard or inboard Telnet servers and the like.

A user can tell you when they’ve lost access to a legacy application. An IP device manager can notify you if a router is becoming overloaded. But it still requires a human being putting these two pieces of information together to understand that a particular application or set of users will be impacted by this congestion. The outsourcer I referred to earlier estimates it took them three years to adequately train "Steve" in handling the breadth of this entire end-to-end environment. And they are currently paying him more than $50 an hour for his special skills - as well as living in fear that Steve might one day leave the organization.

From the end user side, a typical reaction to a hang or performance problem is to shut down and restart the terminal. This causes two problems. First, a network bottleneck is unreported and can either resolve itself or build into a major problem. Second, end user frustration is building with no relief in site because no one is actually working on the problem. Because of this ctrl-alt-del mentality, TCP/IP can have a bad reputation among end users. At Mobil Administrative Services in Dallas, Texas, a network administrator reported that users claim their SNA sessions are more reliable than tn3270, even when their SNA sessions are just encapsulated and routed through the IP network!

Beyond end user perception, there are real problems in the data center in terms of managing TCP/IP connections running through the mainframe stack. Help Desks rarely have access to the network management tools that would enable them to participate in problem solving. Diagnosis requires logons to different operating systems and manual correlating information, such as the application, terminal LU or IP connection. Running a timely GTF trace is a daunting task as it requires one to have console access, knowledge of the command format, and the ability to determine the required connection parameters before starting the trace. Reviewing SNMP information on a router is beyond the capabilities of all, but the most highly trained Help Desks.

And when diagnosis moves from the IP network into the OS/390 TCP/IP stack – UNIX or NT-based tools stop short. Efforts to correlate each leg of the end-to-end communication must be done manually, matching the LU to the IP connection.

In the end, the "buck gets passed" quickly. Diagnosis and resolution of TCP/IP problems are handled entirely by level 2 support staff, putting your "Steve(s)" on the front line. This is true in data centers running just 15, all the way up to thousands of concurrent TN3270 sessions.

The various factors discussed in this article make this environment a good candidate for management procedures and tools. These tools should be aimed at reducing problem resolution time and skill set requirements by providing an easy-to-use interface. The tools should have the ability to correlate various sources of information, as well as easily automate redundant tasks. Factors to consider when planning for migration to and management of this 21^st century configuration:

• "End-to-end" should mean correlation of IP, SNA, OS/390 TCP/IP, inboard and outboard Telnet servers, and SNMP from the application to the desktop. If it doesn’t you will have to make up the difference with trained staff.
• Integrated and comprehensive products or suites should provide functionality for command, control, automation, performance, capacity and accounting. The fewer hardware and software platforms you need to deploy, the less training and ongoing maintenance costs you’ll pay.
• Additional cost of ownership issues, such as supporting a coded solution, should be avoided. Management tools should be easy to customize and adapt to a dynamic environment. Don’t get locked into a specific solution such as a single vendor’s stack, because infrastructure improvements are occurring rapidly and your business will need to take advantage of them in order to remain competitive.
• Ensure you have support for the most critical pieces of your entire configuration including IP devices, inboard and outboard Telnet servers, and the number and type of TCP/IP stacks you are implementing.

Managing and maximizing the new environment where TCP/IP networks are integrated with standard enterprise-server functionality can be a significant task, at a time when data centers can scarcely afford the extra effort required. Understand what your network needs are today and estimate generously about where you will grow in the future. Then, select a management tool to aid you during migration instead of using the pain caused by your migration to justify buying a tool that maintains what you’ve just achieved.

ABOUT THE AUTHOR:

To Marini Sidebar