CA OPS MVS Event Management and Automation Review

Individual rules for various events can be updated in flight without bouncing the product.

What is most valuable?

  • SSM keeps startup and shutdown of all tasks synchronised in a hierarchy.
  • MSF - cross-system and cross-Sysplex links between instances of the product.
  • OPSLOG - similar to OPERLOG, but it also includes some SMF events, and it can be filtered to ease analysis.
  • Individual rules for various events can be updated in flight without bouncing the product.
  • Global variables can be set at the job, system or Sysplex level.

How has it helped my organization?

OPSMVS has made it possible to run our IT systems with fewer staff, due to the level of automation that we are able to use.

This does mean that skills tend to be lost over time, as people are no longer carrying out manual tasks. Therefore, it is vital to have both high stability and meticulous user-maintained documentation.

What needs improvement?

  • SSM - when OPSMVS is started, there is a choice of either assuming all microhooks are up or all are down and working from there. It would be better if there was a feature that could discover the true state of every microhook.
  • OPSLOG - merged OPSLOGs from multiple systems in a Sysplex, live, would help in problem determination.

For how long have I used the solution?

We have been using OPS/MVS since 1992.

What do I think about the stability of the solution?

OPSMVS tends not to fall over. I have to cast my mind back to the 1990s to the last time it crashed in production, and even then, it's easy to restart.

What do I think about the scalability of the solution?

I did not really encounter any issues with scalability. We were warned of an issue with the number of MSF links that could be up simultaneously, but that was resolved years ago.

How are customer service and technical support?

Technical support tends to be good. Sometimes first-level support seem to have trouble understanding an issue when we first present it, but once we push it to second-level, they quickly grasp the nature of our issues and get to work on them. Crit 1 & 2 issues go straight to second-level support. Sometimes a fix is already available and we have somehow neglected to apply a PTF. Otherwise, we can usually expect a fix to be written, tested and sent out within a very few days. CA are not averse to joining international conference calls to get to the root of a problem.

Which solution did I use previously and why did I switch?

We started out with IBM's "AO NetView", now known as SysView. It has a Message Automation Table (MAT), which can drive REXX execs to run in internal servers. At the time, there was no option to continue processing a message after the first hit in the MAT, so it was easy to configure it such that a given event would never trigger the desired automation. The entire MAT had to be reloaded for every change. There was no meaningful cross-system communication. There was no "front end". The product required thousands of fixes a year. We were discouraged from using a large number of global variables (we use thousands in OPSMVS). There was no equivalent to SSM.

How was the initial setup?

OPSMVS also uses REXX, albeit its own flavour. Some code could be converted virtually unchanged.

Converting from the MAT to rules was a much longer process, more time-consuming than difficult.

As many MAT entries had no message-ids coded, we had to determine what the actual message-ids were before we could convert them (another reason for dropping AO NetView). We initially tried coding each of these entires as ")MSG *" and then capturing the text in each rule, but that almost killed JES2 as we had more than double figures of such rules. It was a bad idea, so avoid having more than one such rule.

We had to run both products concurrently for about two years during cutover, being careful not to have them fight each other.

What's my experience with pricing, setup cost, and licensing?

I have no idea what price/licensing we have. Make sure you know what's included in the base product and what you have to pay extra for.

Which other solutions did I evaluate?

We wrote out a list of requirements and sent it out to about 10 vendors. Those which most closely matched our needs made it onto the shortlist, namely OPSMVS and AUTOMATE/MVS. We were then instructed to include IBM's product (now known as SA/390) because it's IBM. We visited three other UK sites, one with each product, saw them at work and asked for opinions. The IBM user said it was "crap". The other two were equally good, but the vendors revealed they were about to merge products and we should go with OPSMVS. We have never looked back.

What other advice do I have?

CA give a lot of support as standard for converting between products, including sample rules and REXXes. Use all the support you can get.

Which version of this solution are you currently using?

**Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
More CA OPS MVS Event Management and Automation reviews from users
Find out what your peers are saying about Broadcom, IBM, BMC and others in Event Monitoring. Updated: July 2021.
523,431 professionals have used our research since 2012.
Add a Comment
ITCS user

author avatarit_user496824 (Vice President at a tech services company with 51-200 employees)

Hi Art, long time no talk. CA has begun running annual technical conferences for OPS/MVS users similar to the OpsXchanges of years gone by. - Scott@ProTech