CA OPS/MVS Event Management and Automation Review
Individual rules for various events can be updated in flight without bouncing the product.

Valuable Features:

  • 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.

Improvements to 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.

Room for 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.

Use of Solution:

We have been using OPS/MVS since 1992.

Stability Issues:

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.

Scalability Issues:

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.

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.

Previous Solutions:

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.

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.

Cost and Licensing Advice:

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.

Other Solutions Considered:

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.

Other Advice:

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

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.
1 visitor found this review helpful
7f0ca799 5b70 4170 b60f c74837d8a5fe avatar


7f0ca799 5b70 4170 b60f c74837d8a5fe avatar
Scott Redmond Mc FallReal UserTOP 5

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

Like (0)15 August 16
Anonymous avatar x30

Thanks Scott.

Like (0)23 August 16
Why do you like it?

Sign Up with Email