OPS/MVS Automation Intelligence Reviews

• Rules
• OPS/REXX
• SQL
• SSM
• Global variables
• OPSLOG

We control our DR tests with OPS/MVS as a wrapper to IBM’s GDPS so our operations staff does not have to manage using their interface in NetView. We also have other “applications” like managing logical engines on LPARs.

Our last main complaint was having sysplex-wide variables (outside of OPSHFI), but this is now a reality.

If you look in the v12.2 command and function reference manual, there are sysplex variables. As in, their scope is sysplex-wide. If you update one on system A, it is accessible from system B.

Prior to sysplex vars, the only option was to use OPSHFI (also documented in that manual), which uses a dataset that is accessible from all systems. There are, however, still some restrictions with sysplex vars as far as which kinds of rules you can use them in, which is also the case for OPSHFI vars.

I have used it since 1997.

We have not really encountered any stability issues. We’ve had a few cases over the years where the product would shut down due to command or message rate exceeded but those have been mitigated.

We have gotten close in one or two cases with the size of global variables but no show-stoppers.

Technical support is excellent.

In a previous life, I supported NetView and also the old Auto-operator. OPS/MVS is much more intuitive to use, especially compared to Netview/SA/GDPS.

We have another team perform the install and we do some customization or test new features. From what I understand, there are no complaints about set-up.

- NetView

I would advise others to simply install it in a test environment first, then play with all the features. I know there are also many samples and tools provided, such as how to set up a table to start up your system tasks.

By far, the most valuable features of this product are:

• SSM
• AOF
• OpsLog

Our largest LPAR currently has 633 tasks defined to SSM. We can shut the system down and have it back up in 30 minutes. Without SSM, that could not be possible.

I think some of their built-in functions are short on functionality. We have written homegrown REXX functions to perform many of these.

• There is nothing in place to ensure that your rules are consistent across all machines in an environment. I have worked at large (20+ LPARs) to gigantic (200+ LPARs) shops. The key to having good automation is to make sure all the rules and REXX execs are the same everywhere. Otherwise, you lose track of changes and differences very quickly. Obviously, some rules might only apply to one system, and we code them accordingly. (CA says that they are working on this currently, and I have seen a demo which looks very promising).
• To go with the previous topic, we have a function called PLEX that returns the current logical sysplex that the rule or REXX exec is running on. Currently, with the provided tools, you would have to code a long select and list each system.
• There is no function within OPS/MVS to open problem tickets to an outside product. Currently, our problem management tool is ServiceNow. We automatically open problem tickets and assign them to the appropriate group all automatically. This function I did demo for other companies at CA World in 2010. Some were very interested in what we have done.
• There is one built-in OPS/MVS function that actually does not work at all. If you are using OPSVALUE to retrieve global information cross-system, there are times that it is not possible to get the information. The reason is you have to pull the data one level higher than what is needed, and you are limited to a number (I do not remember exactly what the value is) that can be returned cross-system, and it is less than what is retrieved from your request. We wrote a function that will look up global information on the system where they reside and return only the info that is needed. This one I have opened a problem ticket on, and have posted it to the CA website.

These are the biggest issues. Some of these I have opened issues on, and others I have just posted online. So far, the only one that seems to have gotten attention is the first one.

• Current employer: 11 years
• Personal experience and usage: 14 years

I have not encountered stability issues very often. It is a very mature product, so there are usually only minor issues.

As mentioned, our largest LPAR currently has 633 tasks defined to SSM. That kind of shows that there does not seem to be any issues with how big a system can get.

Technical support is very helpful, and usually extremely responsive.

We previously used and we continue to use a different solution. (We still have two LPARs on a different solution.) The #1 reason we switched to this product was the ease of operations and the hands-off approach in day-to-day usage.

There are some things that are different, but that is true for pretty much all products. Overall, it is very easy - time consuming because of the code having to be rewritten - to convert to OPS/MVS.

OPS/MVS tends to be one of the more expensive products if you strictly look at the licensing costs. The ease of use and operations more than makes up for that cost, however.

I have been working with system automation since 1986. I have used or evaluated probably six different automation tools. When we made the decision to switch, OPS/MVS was the only option that was considered.

If converting from a different product, all of your existing code (REXX, rules, clists,...) will have to be rewritten. It is NOT hard, but it is time consuming. If you are installing automation for the first time, use the samples, and be aware that automation is an evolution and it takes time for everything to fall into place. Once it does, life becomes MUCH easier and system stability improves tremendously.

• System State Manager (SSM) and the RDF, EPI, POI REXX functions and commands
• Global variables
• MSF
• OPSLOG
• Archive capabilities

After implementing SSM, we dropped our IPL time from 40 minutes via manual commands to eight minutes via SSM.

Use something other than CCI for external communications.

I have been using it 20+ years.

I have not encountered any stability issues; very stable product.

I have not encountered any scalability issues; very scalable.

Technical support gets the highest rating; always knowledgeable and good response time.

I did not previously use a different solution.

Initial setup was very straightforward.

Before choosing this product, I evaluated BMC Control products, IBM.

Make sure to allocate enough space for the OPSLOG and for the global variables.

OPSLOG, message rules, ability to manipulate the msg autoflag, MSF, RDF Tables. The whole product is very valuable, but if I have to list some, those are a good start.

The product is so advanced in all ways that it's hard to pick a specific area. OPSLOG and MSF has saved us more than once when a system was unavailable via TSO, but we could see what was going on via our cross domain logs. This allowed us to correct the problem with an actual IPL of the system.

The ability to manipulate the autoflag has allowed us to setup the kind of message forwarding that is important to our end users.

All of the OPS/REXX built in functions are great. We've recently used OPSTATUS to give our operators extra info they needed about WTORS that wasn't available via system commands.

We initially installed OPS in 1989 when it still was part of Goal.

It is an extremely stable product.

We're a large shop with many requirements and scalability has never been an issue.

The technical support is top notch. They have always been right there for us whenever we were needed, including the offer to be available on weekends during a recent upgrade if needed.

Friendly, professional, knowledgeable. I rate OPS/MVS technical support amongst the best support in the world.

We had a home grown product before choosing OPS.

Our initial setup was not overly difficult, but support was sent out to help us with our initial install.

I'm not involved in pricing and licensing. I'm aware that OPS (as well as other CA products) are considered to be pricier than most. Having said that, you get what you pay for. If you want the features and reliability of Cadillac, then you have to be willing to pay for it.

We evaluated basically all available options, narrowed it down to CA, BMC and one other (now absorbed) company.

If you're at the point of implementation, take advantage of CA technical support and the local OPS online community. Both are extremely helpful and willing to give advice to help new people avoid potential problems.

System State Manager and all the built-in functions.

It’s invaluable for expediting the shutdowns/IPLs of our z/OS LPARs and monitoring our z/OS LPARs for issues/problems.

It needs to have more compatibility/interfaces to other vendors’ products.

I've used it for more than 15 years.

Upgrading the product, either adding maintenance, or moving to a new release, is usually painless.

Some earlier releases crashed occasionally, very rarely with recent releases.

Adding OPS to a new LPAR or removing it from a decommissioned LPAR, hasn’t caused any issues.

Excellent – very helpful and knowledgeable.

When I first started using OPS, there were not any similar products from other vendors, with all the features OPS provided.

Once you're familiar with the product, it’s easy to use. The documentation is very good – coding some rules for console ‘message suppression’ is a good way to start.

The pricing for the base product is probably comparable to other vendor’s offerings. There are some optional applications/features, with separate pricing/licensing, that can be added to the base product. Get a trial license first to determine if any of the ‘optionals’ are going to be of use.

OPS was already in place here when I became administrator.

Ask the vendor for a demonstration of the product.

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