OPS/MVS Automation Intelligence Reviews

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

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.

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

We have been using OPS/MVS since 1992.

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.

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

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.

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.

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.

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.

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

The effectiveness and stability of the solution is something that we require and something that this solution delivers.

It’s a mature product that does what it’s supposed to do and does exactly what we bought it for.

I’m not aware of any complaints from my team; I hear nothing but good things. It was, however, a complex setup in the mainframe. Setup should be made much more straightforward.

After the initial setup, it's deployed without issue.

Today it handles everything very well. A while back, that wasn’t the case, but now it is and we are content with it.

It has adapted well to the mainframe, but we haven’t ported it to any other platform though.

Technical support is knowledgeable and responsive. Although they're not as proactive as I'd like them to be, it's has gotten better over the years. They seem to handle tickets only if it’s over a certain priority level, in which case they jump on it pretty quickly.

It was a complex setup in the mainframe environment. The product is feature rich, so you don’t know if you have it implemented correctly most of the time.

Make sure it’s the right product, get a strong proof of concept, and, importantly, get the right expertise.

We used to us an IBM product, but OPS/MVS has a lot more flexibility in what we can do with it.

We're able to do a lot more ad hoc-type things. We can set up for different events, or do out-paging for a mainframe interface, or issue MVS commands. It's flexible enough for us to use it when needed outside the normal automation flows.

We obviously also use all the basic functionalities of it, like time-of-day, message, and other command rules. Command rules are especially great when our operators have repetitive tasks.

One of the things we've been wanting to do is to be able to automate off of different highlighted messages without actually knowing what the message is. For example, we'd like to be able to create some generic automation when we receive a warning or alert message to allow, if nothing else, the automation team to know so we can contact the product owner. If there's something we can do to automate or expedite notification to the proper people, we want to try to do that.

It's a very stable product and the releases are really good.

Our company size is around 10-15 thousand. Our ops team is a few hundred people, and it's served us well.

We've had to use it on occasion. They've always been very responsive.

I wasn't involved in the initial setup although I am still working with someone who was maybe 20 years ago. It's grown with us and it'd be difficult to switch.