In long-ago days (decades) real-time monitors for IBM® mainframes were chosen by technicians based on what they liked. Over time, technicians became comfortable with their chosen monitor and resisted any arguments for changing monitors. But as mainframes became prime targets for IT cost-cutting, management developed a belief that “a monitor is a monitor” and essentially a commodity item, so they could select the one with the lowest price.
A strange thing has happened to this approach to mainframe monitoring: mainframe sites are learning that there are differentiations between monitors, and that the choice of the right systems management solution can have quantifiable financial and business benefits. In this series of blogs, I’ll share five tests you could use to determine whether your monitor is a business value provider, or…is just a monitor. This blog shares tests 1 and 2.
Efficiency. Monitors run all the time. They add overhead to the environment they are monitoring. They drive up the MSU consumption during the 4 Hour Rolling Average (4HRA) peak, which increases the monthly bill for all MLC software. Monitors can impact critical work during key business periods and times of stress. The CPU efficiency of monitors can vary widely across vendors, with some monitors using as much as fifty percent less CPU than others. Find out how efficient your monitor is, and determine the true financial impact of running it.
Intelligence. The higher performance expectations and volatility fostered by digital engagement plus the retirement of skilled mainframe technicians create a double-whammy for mainframe IT. Mainframe demand and operating conditions now change rapidly and dynamically. At the same time the institutional knowledge and experience with which technicians solved performance problems is disappearing. A monitor delivering real business value will accommodate these changes through:
- Machine learning and analytics to determine what the new “normal” is for operating metrics, and then apply the learning in setting alerts and alarms
- Automatically recognizing, identifying and responding to typical conditions that require attention
- Built-in domain-level expertise, to replace some of the knowledge and skills of departing technical staff
Where do you stand? So, to reiterate: is a monitor a monitor? Is mainframe monitoring a commodity? How do your monitoring tools stack up to these two tests, or to the other tests? Is it possible you might improve availability and performance, reduce costs and make the mainframe more secure by evaluating a differentiated monitor as an alternative?