In-Depth

Perspective: Six Challenges of Managing Mainframe Connectivity

From changing rules to technical complexity, a network manager's job is tough. We explore six challenges of managing mainframe connectivity in the first of a two-part series.

• By Warren Jones
• 05/04/2004

In the good old days of SNA, things seemed much more predictable and the management tools much more helpful. In reality maybe it wasn’t that easy (remember, I’m getting old, so I forget things easily). Regardless, the fact remains that today we are faced with numerous challenges in ensuring network connectivity to the mainframe.

First let’s look at some of the challenges that we face in mainframe network management today. Next week I’ll offer insight into what software vendors are doing to help.

Complexity

There is no denying that today’s networks are much more complex than ever before. As organizations migrate from SNA to router-based networks, SNA doesn’t magically go away as most of your applications continue to be SNA based. Technology continues to evolve and you are left supporting an “at least one of everything” network.

Data Volume

Rather than not having enough management data, today's network today provides too much management data. In an IP-based network, devices support SNMP and the extraction of MIB (Management Information Base) data. We all know how much fun it is to look at a MIB. It is difficult to gain an appreciation for what data is significant and what is not. Multiply this complexity by the large number of devices in your network and the problem is exacerbated.

Furthermore, not only can management data be extracted from MIB data, but there are also other data sources (such as SMF, packet tracing, and other SNMP commands), each adding additional and overlapping pieces to the management puzzle.

Data Comprehension

How can I possibly complain about having too much information? The problem really is being able to comprehend the data. If we can’t easily make sense out of the data being provided, then having too much data only serves to add to the dilemma. The management data we gather today -- especially in terms of MIB data -- makes it very hard to have a true appreciation for what is a problem and what is not. Looking at particular performance metrics without an appreciation for what is normal, makes it difficult to set meaningful performance thresholds to assist in proactive management of your network.

Today’s management products are very good at exposing management data, but not in helping process the management data.

Changing Rules

SNA is a proprietary architecture. IP is open and standards based. These are two obvious statements, but how does it affect the resulting networks and their associated management?

During the 1980’s, IBM had sole responsibility for setting the rules for an SNA network. The majority of the hardware devices used in an SNA network were developed by IBM. Even those that weren’t needed to support network connectivity as if they were IBM devices.

Today, with IP networks, there are many different network hardware and software vendors involved, and although standards provide the guidelines for development, it is often up to the vendors as to the level of standards they implement. Additionally, standards are continually evolving and new standards being accepted serving to further add to the disparity between alternative offerings. The goalposts keep moving.

Reactive Monitoring

In my role as a product manager, I talk to many customers about their use of network management products. One of the questions I like to ask is, “How do you know when you have a problem?” Time and again the answer is, “The phone rings”. Now, this is disappointing for me to hear, but I have to believe that today’s management products are not all (us) vendors make them out to be.

The truth probably lays somewhere between, not being able to set meaningful thresholds due to a lack of understanding of what is a problem and the management products not making it easy enough for the user to determine when a problem occurs. Management products allow for the setting of triggers based on performance metrics values, but without providing the network “know how,” these features are rarely used or commonly underutilized.

Resource Availability

Not only are our networks not like they use to be, neither is the economic climate. Renewed focus on the cost of IT following the heady days leading up to the dotcom collapse in 2000 see the ever increasing requirement for us to do more with less. Some twenty years ago I started out as a network operator. I worked on a shift, which had a total of eight people -- four shifts in all -- responsible for managing what was then primarily an SNA network. When I last visited that organization the shifts had been reduced to two people and their responsibilities had also increased significantly.

Was the job any easier? No. Was the network simpler? No. Was there a need for a higher level of availability? Yes. Often management tools are used to justify reducing employee head counts, but today most significant staff number reductions are a result of corporate cost cutting exercises.