We use it to schedule our production workload.
We use it to schedule our production workload.
We scheduled our database maintenance jobs through ASP and when we did this, we scheduled them in a certain defined way that we expected them to run. And when that was initially set up, there was no consideration for a database not being available so if the jobs tried to run when a database wasn't available, obviously they wouldn't work and an operator would have to intervene.
The plan was that people would open requests to have jobs held at that time. When there were only one or two databases, that wasn't hard to maintain and people did it. When we grew to many, it became harder to do that. Then with the change in how we're doing stuff, everything happens more, servers get booted more, more changes.
We use features of the product that allow us to determine if the database is available and to only allow the jobs to run when the database is available. So that saves a lot of manpower in the one group that was opening requests to hold jobs, and in the other group which had to implement the request to hold the jobs. It eliminated all that and provided a more dynamic environment for when these jobs can run, without operator intervention.
That is something we started about two years ago. We fully implemented it last year and we've noticed a big savings in manpower.
It's easy to use. When you schedule jobs, if you can speak English you can schedule them easily and correctly.
There's a lot of flexibility because the product allows you to do many tasks, in multiple ways, so you can choose the way that works best for your environment.
How they handle cross datacenter failover, because they have a really good High Availability solution that works well within a single sysplex, but in our environment, since we have two main datacenter locations, we have two separate sysplex. And, while when everything is working ASP can control jobs both here and in the other location, the current product does not support High Availability across datacenters. That is something we would like to see the product have.
Currently, what we have is we have a homegrown solution, because we're required to have that kind of resiliency, because it's our enterprise job scheduler.
When everything's working, we're invisible. When it's not working: "Why aren't you working?"
Stability is a 10 out of 10.
Scalability is a 10 out of 10.
Tech support is a 10 out of 10.
When I started, we were already on this product, but I do know that they were using a competing product before and they felt that this product had more of what they wanted. So they converted from the competing product to this product.
When the company chose this product, it was actually pre-CA, and then CA acquired the product. But for the most part, they've kept it what it was. While it has a new owner, it's still the same product.
I believe it's pretty straightforward. It's a complex thing by nature so it's not going to be super simple, but it's not like you can't do it either.
I believe experience helps. And in our case, we had a lot of help from the vendor, so while we, per se, didn't have the experience, there were people helping to get us going that did have the experience. So maybe I'm underestimating how much that was important, because it was available, even though it wasn't coming from me or one of my team members, but somebody else was providing it.
I'm really the technical guy. Pricing is not something that I deal with so I can't answer that question.
That would have been 20 years ago, so the market is a little different than it was back then. There are solutions today that did not exist back then. Pretty much all of the big players still exist today. But we're definitely in a different place today than we were back then.
No advice other than the normal stuff that you would do when looking at any product: Does it fit what you need?
I would recommend doing a proof of concept before signing any contract. Everybody's stuff sounds good on paper and everybody's stuff can do everything, but what happens when you bring it in your environment? Does it do what you need it to do? Those are the most important things. The other stuff, while it's nice stuff, if you can't do what the product is required to do, then there's no value to the product.
For us, it gives us what we need so it's a good value. Forget about the price, because if the product doesn't do what you want, it doesn't matter what the price is.
I would rate the product a 10 out of 10. We use the product everyday and it works and, for the most part, every time we have a problem, it seems it's never my product's problem. It's: I have a problem because there's a problem on the system, so guess what? We're not going to be working. I need a stable system to run.
Or if it is our problem, maybe we didn't do something we were supposed when we found out that we were supposed to do this, and we reconfigure something and then we move forward and we don't have that problem any more. Or we re-architect how we do stuff, because we've had to make tweaks of stuff as we've gone along. We would do stuff and it would work and then we would do something a little differently, and what we did, it didn't work and we'd have to figure out what the problem is and fix it.
Again, the flexibility of the product allows us to do things multiple ways. We might have started doing it one way and that worked for a while and then either something changed -whether we had more volume or we did something a little differently or we had different issues - and then we would address them with different tweaks, solutions.