How to Reduce Costs for Managing z/OS Networks

In today’s economic environment, many enterprises are clear in cutting their IT budgets. However, the IT demands remain intact and are not reducing to accommodate the falling expenditures. In this scenario, it is highly important for IT administrators to cut waste and do more with less. In the case of monitoring and managing z/OS networks, there is significant opportunity for cutting costs by replacing NetView®.

NetView as network management option for z/OS
Tivoli NetView from IBM has been helping z/OS administrators manage the mainframe environment since the late 80s. IBM has been releasing updates of NetView regularly with additional features and enhancements. However, many of these features are not used by mainframe customers, but they still pay for them.

Suitability of NetView for modern mainframe networks
The first version of mainframe NetView (V1R1) was released in 1986 when hierarchical, mainframe-centric SNA networks ruled the corporate roost. The SNA SSCP functionality, implemented within mainframe VTAM, activated, controlled, sustained and managed the network. Mainframe NetView, originally just the bundling together of prior SNA-specific network management products, viz. NCCF, NPDA, and STATMON, was meant to complement and enhance the SSCP functionality.

In the mid-1990s came TCP/IP, the web, and the rather rapid demise of SNA networks. The basic rationale for mainframe NetView changed dramatically. NetView persevered, throwing in more and more functionality—SNA, TCP/IP, Sysplex, APIs, gateways and cross-product interfaces—rather than giving customers the option of buying smaller, targeted management solutions.

Currently, many NetView customers utilize only a selected subset of its sprawling functionality. Thus, there is significant opportunity for reducing costs if they can pay only for what they use.

Determine your current dependence on your network management tool
Many organizations use NetView, with REXX-based scripting, for some of their mainframe automation. Some of the other core NetView for z/OS functionality is the command line interface for system/network commands, system/network message concentration and logging, SNA end-to-end session monitoring, system log browsing for problem determination, and real-time monitoring of system/network status.

But there is a long list of functions for which NetView can be easily replaced, saving money in the process:

  • NCCF functions
  • Browsing of network and system logs
  • Message and event automation
  • Browsing of datasets
  • Panel applications
  • Session awareness
  • CICS automation to start and stop transactions, and monitor job completion
  • Monitoring Enterprise Extender, recovering connections, and storing EE device status
  • Issuing alerts regarding batch-job ABENDs
  • Monitoring the JES spool and purging output
  • Issuing commands to restart TCPIP devices
  • Responding to messages from TSO users
  • Monitoring CSM storage on TCPIP and VTAM
  • Periodically testing connections to remote partners
  • Command routing and response in a sysplex
  • Monitoring MQ messages
  • Response HSM recall requests
  • System IPLs and shutdowns
  • E-mailing users about events on their systems and networks
  • Executing REXX scripts to ascertain the “health” of networks

    Potential for realizing quantifiable cost savings
    If your NetView for z/OS usage falls within the core functionality outlined above, you should, most certainly, consider replacing it with a solution that is likely to provide you with immediate, tangible, software cost savings.

    NetView for z/OS is entirely mainframe-based; it utilizes expensive CPU cycles on z/OS LPARs for everything it does. Hence, you are using mainframe MIPS even to browse a system log. You can go for an efficient replacement that off-loads nearly all of the requisite data consolidation, data analysis, and data presentation functions onto less costly Windows or Linux server platforms (keeping in mind that even the cost profile for a Linux LPAR is significantly lower than that for a z/OS LPAR).

    Why go for more efficient replacement
    If you use only the core, baseline functionality of NetView for z/OS i.e., REXX-based automation, command entry, message consolidation, system log browsing, and system message decoding, you need to seriously evaluate why you are paying for the features you don’t use. There is possibly a raft of functionality in NetView that you are not using, but are paying for indirectly. You can avoid it by opting for more efficient replacement.

    Most people think that replacing mainframe monitoring software is an additional expense, as they have to purchase another software product. But, if your new software can save you more money compared to your investment in the old one, it definitely makes sense to go for it.