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.

We have managed to avoid a lot of incidents with it. We can, in fact, with OPS/MVS cope with some incidents before they happen.

The product is really a very good automation. It's around the Rolls-Royce products of the automation products that are around. It's a very stable product. I very much like the SSM stuff in it. The rules engine, it's awesome.

There is always room for improvement and new features, and we like new features, so if CA delivers them, we are happy to use them.

Before, we had downtime without the product. Now we can, in fact, avoid the downtime with it.

It's very scalable. You can automate with it, a 1CP, and for the moment we have around 200 LPARs. So you can, for one LPAR, it's a logical partition... or with 200. It's very scalable.

Very good, because if I open a ticket with them, I get instant reaction, and the solution is also very fast.

It's relatively straightforward. It's not so complex. Of course, if you are a newbie, it will be more complex than for someone who has done it before.

Regarding important criteria when selecting a vendor, it's all together: It's the stability, it's the support. I also know some of the developer guys, and that's really an add-on if you know them, and you can talk to them straight here at CA World.

It's definitely a 10 out of 10, because it's a very stable product. It's a really fast product. It's one of the best on the market. I compared other products like stuff from IBM, BMC, with it, and it's nothing like anything else on the market for the moment.

We use OPS to manage our workflow with jobs.

It performs great.

It does what it's supposed to do. What we need it to do is just bring our tasks up and bring them down, and in the right order.

It brings up the jobs. We can schedule them into different groups, so we can bring up the base system first and then the applications just run on top of the that; then the jobs that aren't quite as important after that. 

We can enter special commands. It can go out and see messages as the job comes up, and you can reply commands to the messages. 

Satisfies the dependencies. 

What I like about it personally is that I can go out and interrupt what's going on and bring a job down if I need to, and bring it back up. It works out really well.

Some of the commands are long. For example, to start a job, instead of just doing "s" plus space, to start a task, you have to type in "ssm", space, "sj", space, "job equals." That's how I do it. I use the commands. I know that you can go into a panel and kick things off in a different way. Maybe that would be easier.

As far as I know it's stable. I think we did have one crash. I'm a user of it, I don't support it. But there was a crash.

I believe it's scalable.

I have used technical support and it works great.

It works well. 

Our primary use of OPS/MVS is automation on the mainframe system, controlling resources, and tasks. 

The performance of it is beyond exceptional. It is probably one of the best products that I have ever worked with. It is easy to use, comprehensive, and can perform almost any task you need it to. 

• Simplicity of use
• Reliability of the product
• Scalability
• The performance functionality

The width and breadth of the options available that we do currently not use, but are available to us.

The further expansion of the mainframe teamcenter interface. Also, the web services support is something that I am looking into.

Though, it currently meets my needs perfectly the way it is.

The GUI interface could be improved, but that is coming. They are working on that.

Stability is probably the best out-of-the-box. Put it in, set it up, and you leave it alone. It works wonderfully.

We have had very minimal problems, mostly of our own causation.

I have been using it as my own user for over twenty years. With the bank, since I have been there, seven-plus years.

Scalability is simple and easy. We just built another system, put Ops on it, and built it in less than an hour.

We have not had any issues with the scalability.

Their technical support is incredible, immediately responsive, and even if it is not updated to Level 2 support sometimes, they chip in providing more detailed answers and options to fix the problem.

I was not involved in the initial setup, but I know it was straightforward. The documentation is simple, easy to follow, and use. A limited, first-time systems programmer can do it, in that it is out-of-the-box almost functional.

No.

Most important criteria when selecting a vendor: 

• Cost
• Functionality
• Cost of the business.  

We use it to monitor day-to-day activity in the system and to automate things like start-up, start a task. Basic overall health of the mainframe, and day-to-day business as usual.

It has performed very well.

It allows us to respond faster to issues. If there are issues that come out, we're able to capture a message and alert somebody about it.

The simplicity of it, as far as getting new people to use the tool.

It's very flexible. You can customize what you need to, which is good. For example, you can do your own coding inside the tool, make your own scripting tooling.

The scalability. We're able to use it across our whole enterprise.

It does everything we need right now, I can't know of anything else we really need at the moment.

If I really had to put my finger on anything, mainframe tools are pretty old as far as the pricing models. Maybe that could be improved. Should I be able to buy whatever I want, and then I pay for what I use? Or maybe I don't pay anything for the product, and I then pay for the support. More of an open-source model.

It's good. It's been very stable for us, for the 10 years we've had it.

Like I mentioned earlier, it goes across the enterprise, so it's been very scalable.

We use technical support all the time for it. We're a big shop, we have a large enterprise of system. So there are a lot of issues that come up, or sometimes it may just be a question about the product. Maybe we're doing an upgrade and you need to know, "Am I doing the right thing?"

They're good. We haven't had any issues. Responsive, absolutely.

The path we were going down was between IBM and CA, and we thought about which one we should go with. For us, the flexibility and scalability is what sold us on this.

Just IBM, in addition to CA.

Our most important criterion when selecting a vendor is how closely do we partner with them, that is the biggest thing for us. What kind of attention do they give us when we have issues? We're satisfied with that with CA.

I give it an eight out of 10. There is always room for improvement. To get it to a 10, I will know when they do it. Maybe it's cheaper, maybe it's some new flexibility in the product that we've never even thought about. If they anticipate the industry, what's going forward, what's out there, is it something that you would maybe use it in the cloud.

For the mainframe it's a really good automation tool. It's been really solid for what we needed it for, and it's been flexible and scalable across the enterprise.

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.

Mainframe: Everything from message suppression to posting jobs in CA 7 and opening tickets.

It is performing well.

It watches the slug, the BDIs, and the other systems that we have. It alerts the operators when it is time to repair the communications and the IPLs.

I do not have to keep recordings. It is there and is proactive. It helps the operators, human editors, and me.

I am not using all the stuff that I could use now, so I do not know. It is working very well for us.

There is just so much in there that I am not utilizing, though I might not need to utilize. It is just not knowing everything in the product.

It is very stable. We have had very few problems with the product itself. Mostly like parameter numbers, things change. It needs to figure it all out, and suggest parameter changes.

It is good. Variability with a lot of content. Not a lot of issues and it is automated. Easy to upgrade and easy to support.

The service has been wonderful. I like the people that I have had to deal with. The process is very straightforward. I call or use the website.

The follow-up surprised me. Making sure that I am happy with what I have gone to them on. They will call after I have made changes and verify that I am happy with the changes that I did have to make. If it did not fix the complete problem, they go back over it until I am satisfied.

I was not involved in the initial setup, though I have created and brought in new releases and stuff. The upgrades are pretty easy. When I do have questions, they usually walk me through it.

I don't know which vendors that we were looking at. I was before my time at the company.

I do believe we selected the solution because it was the most robust at the time and the easiest to maintain.

I would recommend the solution. It is a very friendly solution: Easy to upgrade and it is pretty self-contained. It does everything you need it to.

Most important criteria when selecting a vendor: 

• Responsiveness of support. 
• Easy to follow instructions. A lot of times you open a manual and it is like a foreign language to you, if you don't have the knowledge upfront. You need a vendor there to explain it, and CA has been very helpful.

The primary usage is we try to automate the system message, then transfer it to the command to automatically respond to the system requirement message.

To reduce the number of repetitive motions required by a human to respond to the system. This automation automatically replies, so the benefit is to reduce repetition of work.

To minimize the labor of responding to the required message. So, an automatic response is minimizing the labor work.

With stability, sometimes we do have problems with this product. I guess because a lot of times we have to write the script correctly, so finding the right person with the expertise on writing the script, or the automation, is the problem. So, that is the reason sometimes it is not stable, we do not have the expertise to write the script.

So far, so good. We can combine all the CA products and work with this product together, so we pretty satisfied with that.

Because sometimes the system has new messages. Every time we installed another new product, the message is different, so we would have to constantly upgrade, and follow up with the upgrade. That is how we knew that we needed this product.

I was not a part of the initial setup.

We really do need this product. We have the necessity now, because we have implemented for so long that we can't function without this product.

Implement and write the script correctly from the beginning. Make sure and plan out ahead. Plan the project five, six, or seven years ahead, instead of just installing, implementing, and starting. Plan ahead.