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.
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.
It's distribution. The logistics of distribution. Warehousing, distribution, inventory control, shipping, bills of material.
Considering it's 35 years old, it's still functioning well, primarily because of the resources that are available, and tools that have been introduced that can connect to legacy applications.
The benefit is that the ROI, since it's 35 years old, the ROI is coming back over and over and over.
I don't think it improves the way our company functions. Because of its age, it's a little bit difficult to modernize some of the integrations and some of the functions. The people who support it limits us, but at the same time it's providing us benefit.
It's very secure, because it's a legacy application. It allows a natural, organic encapsulation of data.
Definitely having more web-based interface. Definitely be more mobile-open. More APIs, more open source to it.
The product is very stable.
Scalability is zero. It cannot be scaled because of its age. And it can't be scaled because the newer warehouses, or the new distribution units, require far more automation, far more artificial intelligence, far more robotics. This application, unfortunately, cannot be scaled, unless you add more middleware pieces. So it's great where it's at, but modern environments are having a difficult time scaling it.
They're good. Very good. They're efficient. They know our environment. It's a good relationship.
I was not involved in the initial setup but I have been involved in an upgrade. It was complex. It wasn't a major upgrade. It was just an application version maintenance-level upgrade.
It was complex because of the integrations. It was complex because of the availability of the system. It's at 32 distribution centers, so you have to work with one distribution, or a few, at a time. Like I talked about scaling. You had to do 32 distinct upgrades, and they all had their own little engagement, and they had their own little nuances, depending on the location.
The most important criteria when selecting a vendor are depth of support, intelligence on the industries that we are in, and similarities of different organizations so we can leverage their data points to make sure that we have a streamlined approach on support going forward.
I would look at the vendor's internal teams to see if there people capable of supporting it, and what it will take to ensure that there is sustainability around it. And last but not least, what is the roadmap of the product compared to the roadmap of your company? Strategically, they should be in lock step.
We use it to look for jobs that are running late in our scheduling system.
It can save money. If something is late, there are lots of dollars lost.
To help monitor our scheduling system, in case there is something late.
I have never seen it go down unless we brought it down with the system.
I have not used the technical support.
I was not involved.
It is an easy product to use and it is stable.
My primary use case is the automation of all of tasks. I used the scheduling feature and also automation of various time-critical top functions and facilities.
It's made it so that with a lot of automation pieces we can bring this region up or take this region down, and it allows us to actually always meet our time critical requirements. If it's supposed to be up at 8am, it comes up at 8am.
It works, and as far as the scheduling piece, it is wonderfully well-written and I use it all the time.
If something breaks and it goes down when it's not supposed to, automation brings it right back up. So it's really used mainly for availability.
It more or less does everything we need for it to do.
Very stable.
Scalability is really not an issue in the mainframe. It can handle anything we need it for to handle.
They do a good job. I have SYSVIEW and I'll call CA more for SYSVIEW than I would for Ops.
We actually had CA, one of their experts, come in and help us set it up. Now it seems simple, but I have to train folks on it and it's complex, but it does a lot for us. It's complex because it does everything.
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.
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.
Mainframe automation.
In terms of performance, it is the gold standard in mainframe automation.
I personally like its System State Manager tools. They make starting and stopping a mainframe pretty much seamless.
I've always had it, so I don't really know that I can say how it improves my organization. I don't have anything to compare it to.
I don't know of anything that is required to be added.
I've never had any issues with stability.
It's scalable to the mainframe. No issues.
Technical support is good. I work on several CA products, I generally find that they have a very good response time. And if they can't answer your question they always have levels above them that they can send the tickets off to.
I would definitely get a demo and look at this product and compare it to what they're running. All of these vendors have conversion processes, so I'm sure they'd have to do the other stuff that I don't do, make the dollars work. If it works I'd do it.
Automation is very important to any data center; just the ability to optimize things, run more efficiently. OPS/MVS does that tremendously.
I think from our standpoint, from automation, automation is central. We've reduced people from making mistakes. We've actually improved performance because now, OPS/MVS is doing things more efficiently than a person would do; they may make mistakes; finger checks here. OPS/MVS will do it automatically, and that's been working well.
I think, for me, I’d like to see more of its web base. The ISPF dialogue needs a little bit more features. However, the web base will be even more important for me.
We're a beta site for CA. I've been with the company 30 years, so I probably have been using it for about 19, probably about 15 years.
I've been utilizing it for, again, 15 years. I'm happy with what we've seen with CA OPS/MVS.
Interestingly, since we're a beta site, we had the old automation platform. Then, when they merged OPS/MVS to automate, they really improved things with the merge. And then they started building up on it, so it's been scalable for the past umpteen years now.
I get along very well with support. Thankfully, we have a good relationship over the years; just building a relationship with them. They've been responsive to every question that we had. I'm happy about that.
Initial setup and upgrades are pretty much straightforward. Now that we've had it for so long, pretty much, we're just adding on at this point. They're pretty much stable, as far as the initial setup and also upgrades.
We've been asked plenty of times about other vendors, but for us, we've had it so many years. We don't see anything out there that actually meets up to what OPS/MVS is doing for us, so we're comfortable with it.
When selecting a vendor, we look for a vendor that's stable; that’s one of the criteria. A vendor that's been around for a little while that has the future, vision. As far as OPS/MVS is concerned, they have that. They've been working on solutions, different solutions for OPS/MVS, promoting it to the customers, and even getting feedback. That's very important for me, as well: feedback from the customers; having the ability to communicate and say, "Okay. I like that idea. Let's implement that in the next release." So, that's been good.
With any company nowadays, senior people are being shipped out, basically retiring. New people are coming in and, in the mainframe industry, a lot of the newcomers do not know the mainframe. So, having that automation platform in place and having it learn throughout the years, we had to do something.
We started off as a beta site for CA, so we learned throughout the years that it's worked value for us and even reduced head count, so that was a good thing.
I'm happy with what we've seen with CA OPS/MVS.
