Superior Functionality, Better Support, and Lower Price: It’s a No-brainer
Westfield provides commercial and and personal insurance in 21 of the United States and surety services to customers in 50 states, all through a network of more than 1,200 independent insurance agencies. The core systems we need to run our business—for example, quote generation and claims processing—reside on our mainframe. High availability and fast performance have always been important, but they are even more so in the digital economy where consumers expect to receive quotes in minutes and have claims processed quickly and effortlessly.
About a year ago, we decided it was time to check out the monitoring landscape and look for a replacement for our old system. After a careful search, we selected the BMC MainView product family for a variety of reasons that include tight integration across components, a consistent user interface, superior functionality, extensive automation, and compelling pricing. Westfield is currently using MainView for z/OS, CICS, DB2, MQ, and IP; MainView AutoOperator for z/OS, CICS, and MQ; and Pool Advisor and Apptune.
From Reactive to Proactive
Right from the start, we realized benefits with MainView. Our previous solution had only a limited number of out-of-box monitors with little flexibility in alarms. MainView also offers out-of-box alarms, plus it enables us to set up additional alarms for specific purposes. We can define an alarm for anything MainView monitors.
We now have 30 active alarms that issue early warnings for potential problems. As a result, we’ve evolved from reactive firefighting to proactive management. For example, our online premium quote system requires the timely execution of critical batch jobs that normally take about three minutes to run. From a business standpoint, if we don’t get the jobs run quickly and a quote turned around to the consumer within 10 minutes, we probably won’t win the business. So we’ve set an alarm that alerts us if these jobs are not completed within five minutes.
We’ve also added alerts for jobs running outside of class—for example, a test job running in a class for production jobs, which means it is taking away resources from production jobs. With our previous solution, storage violations would sometimes occur when users would send through a bad policy. When they didn’t receive a response, they would send the policy repeatedly, causing the region to abnormally terminate. So, for example, if new code put into CICS created storage violations, we wouldn’t know about it until CICS went down. By the time we were alerted, the damage was already done. MainView acts as an early-warning capability, alerting us as soon as a storage violation occurs so we can take action to prevent an outage.
Looping is another example. Before MainView, we didn’t know when a job or transaction was looping, so jobs and transactions could eat up CPU processing power. Excessive CPU usage would significantly slow down transactions and in some cases caused use to reach maxtasks. Looping was also driving up our four-hour-rolling-average CPU consumption and increasing monthly license charge (MLC) costs. MainView notifies us as soon as CPU usage begins to spike, so we can intervene within the four-hour period to stop wasteful CPU usage and keep MLC costs down.
MainView’s smart alarms also help us better utilize our System z Integrated Information Processors (zIIPs). Before MainView, we specified that if a task typically ran on a zIIP but none was available, the task had to wait to run instead of bleeding over to the CPU. This approach helped us keep CPU utilization and MLC costs in check. Unfortunately, it also meant that the task had to wait until a zIIP became available. With MainView, we can allow the bleed to happen in a controlled way. We set up MainView to alert us of two conditions: When a zIIP reaches a specified utilization rate for a specified amount of time, and when jobs that are eligible to run on a zIIP are actually running on the CPU. That way, we can intervene if our specified thresholds are reached while still preventing excessive and more expensive consumption of the CPU.
In addition, MainView captures a wealth of data that facilitates troubleshooting. For example, not long ago we noticed that an IBM application started a task that was consuming an increasing amount of memory over time and ultimately would cause a production outage. Each outage required an emergency IPL to alleviate the storage constraint. The MainView graphic capability depicted the task’s memory consumption over time and we could see the slow but steady rise in memory utilization. We knew we had a memory leak. We contacted IBM support people who were aware of the problem and sent us a fix. To prevent similar problems in the future, we set up MainView to detect and report any task that is using more than a specified amount of memory, so we now have advance warning of memory consumption problems.
Another huge advantage with MainView is the ability to automate responses to alerts. We can specify automatic actions that are triggered by certain alerts. Because we’re connected to REXX, we can perform a variety of actions: put up a write-to-operator (WTO) message, IPL, or escalate and deescalate alerts. Right now, we’re using MainView AutoOperator mainly to provide meaningful messages to the appropriate people when alerts come in. For example, we can immediately inform developers of issues such as a memory violation and suggest the most likely root cause. That is saving a considerable amount of developer time.
Measuring the Value
With the step up to MainView, we’re benefiting from tight integration across the components as well as the common user interface across subsystem monitors. We no longer have to cope with multiple user interfaces or cumbersome switching from one monitor to another—for example from CICS to DB2. MainView provides a level of monitoring and automation functionality that we didn’t know was possible. We were pleasantly surprised to learn that the additional functionality and automation came at a lower price tag than the solution we replaced. And, to top it off, once we started running MainView, we discovered that it uses 13 percent less CPU than our original monitor, and that translates into lower MLC costs.
Finally, we we’re benefiting from the knowledge and expertise of the BMC support team. We can call the local BMC support technician and get immediate response, whether we have questions, configuration issues, or the need to escalate to a higher support level. More functionality, lower costs, and responsive support make BMC MainView a no-brainer.
These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.