AutoSys Workload Automation Reviews

The integration that it provides and the auditing features are the most valuable to us. It also gives us an end-to-end solution that we can give our clients.

It simplifies everything and also takes human error out of a lot of things.

I would like to see a better front end for job creation that does everything for you, so it also automates the process.

In addition, I would also like to see a job form, i.e., a fill-out form for the job requests. I also want to see it set up files, folders, security, policies, etc., and automate JIL creation.

Now, it has become very stable. In the earlier releases, I have seen some issues but with the current release, it is very stable. We've been very happy with this.

The product is very scalable. With the way we have ours set up, it allows for rapid extension, if needed, but we have never maximized our systems.

We have used the technical support and it's good. They're very knowledgeable and very willing to help.

We have not used any other solution before. We've been using this product for a long time.

You should look at some of the use cases because there are so many people that have so many different setups, with so many different ways to do it. We have found the most efficient way and that is why everyone comes to us and uses our agents.

In my opinion, the most important criteria whilst selecting a vendor is reliability.

The valuable features are stability, ease of use, and the use of scheduling. Our company processes approximately 200,000 jobs a day through this product. The product is very stable and stays up.

The solution helps us meet our SLAs. It helps us keep the product data flowing and the jobs running without down time.

There is always something that can be improved, but I do like this product. It is a good product. The DevOps are there to move the tool into the future. The new path is mainframe modernization. That's where we'll be headed with this product.

In terms of stability, it’s pretty much always up. The solution stays running. We do have our company-wide scheduled outages, but that's the only time it comes down at this point. We are working towards a better solution for constantly being up and CA is working with us on that. We just converted to version 12, and that's a step in the direction of keeping the solution up.

The solution is scalable. They are creating products to help us use GUI interfaces. They are helping us to monitor the system better and keep it going.

I have used technical support, and I would rate them at 10/10. I love the guys there. I know them and they know me. They're very easy to work with. I can speak for this product and say that they know their product and they're there to answer our questions when we need them. If we have an issue, they are there.

I can’t speak much for the initial setup. I just upgraded to version 12 and it was spot on. They had the procedures and jobs in place and I just created my own procedures for my environment. I had no issues.

We have a saying at work, "If there is an issue, CA 7 is the victim, not the cause." This tool is a pretty stable product.

When choosing a vendor, I look for customer service. I want them to be there when I need them. I'm not going to say that they have to have a big name, but I guess cost is a factor as well. Cost is always important. I think cost and customer service are the best things. Those are the most important factors. I need someone to be there when I have an issue, and I need personal assistance to stay up and running.

What I like about it is that we use it as our enterprise-level scheduling systems. We used to have scattered jobs scheduled. They all had problems every day. The troubleshooting made a huge mess for the whole company. After we started using CA Workload Automation, everything became one integrated system. It makes the troubleshooting and monitoring much easier.

We started with Workload Automation 10 years ago. Before we started, we had about three hundred scheduler jobs distributed in different Unix systems, Window systems, AIX systems. Everyday you need to fix some problem. Once we built the Workload Automation, everything was in one centralized place.

As a management firm, every morning we have to be ready to trade, as soon as the stock market opens. To be able to trade, the nightly cycle jobs are very critical. If any one of them isn’t ready, you cannot trade at 9:30. It's always a struggle for us. For a while, we had about five people just for overnight support. After we integrated Workload Automation into our system, we are down to two people.

Like almost everyone else, we like to make it more web-available. Right now, it's a thick client so you need to have a desktop client do all the work and the monitoring. People like to just go to a browser, look for the jobs and monitor them. That is something we’d like to see. I think we're very happy with this system.

We had some problems at first. I guess every new system has some problems. That was ten years ago. We had a very good consultant from CA. He basically became a resident expert for us for three months. He basically enhanced the whole workload, and improved all those workflows for us. After that, it has been running very smoothly for us.

Our total number of jobs grew about five-fold. We used to have about 100,000 jobs a month. Now we have about a half million jobs a month.

We had one time when we did an upgrade, which did not go smoothly. I remember clearly that we had about 53 open tickets with CA in one week, but CA support is very, very good. They eventually sent us someone who was just wonderful. They sent him to our office and he sat down with us on-site, and he helped us with the whole thing. CA support is wonderful.

The technical support is absolutely the most important to us. When you manage support systems, you want to have someone who can back you up. Luckily CA support is very very good.

I think the initial setup is very straightforward itself. The migration is not. It's not because of the system. It's more because of the job itself. Our firm is about 90 years old. Over the years, it has accumulated a lot of legacy systems, and a lot of legacy jobs. You need to spend time to understand the job when you migrate to a new system.

We had so many NT schedulers, like cron jobs for Unix. We know this is not right. At that time, we luckily had a new CEO. When he came on board, he said the first thing we need to do is to have some enterprise scheduling. I was actually the one who was in charge of finding the right solution.

We went to IBM Tivoli, BMC Control-M; and then we also came to CA. What CA did is: instead of just selling some products to us, they actually sat down with us to understand our environment first. Then they come back to us, and say "Okay, I don't think you guys want to have AutoSys. "At that time, AutoSys was famous. Our environment is not big enough. So they said, "We think the Workload Automation dSeries is actually much better for you." I was very touched by a vendor who came to us and gave us the right solution, instead of just selling us something more expensive. That's the whole reason we chose the dSeries.

If you are considering this product, I would say just go for it. The planning is like I said: the systems stuff itself is easy, but the migration is not. You need to understand what you have now before you move on to different one.

CA Workload Automation automates across multiple platforms. We're actually getting rid of our mainframe; so it's allowed us to use a distributive scheduling package. Getting rid of our mainframe is a big deal to my company.

It enables you to tie into audit systems, gives you a lot of visibility as far as workload goes, and allows you to automate it as well.

On the mainframe version of ESP, there was a scheduling parameter called NOTWITH. If you placed this parameter on two jobs you didn’t want running at the same time, ESP would recognize that one was running and the other wouldn’t run, even if its scheduling requirements had been met. This allowed our company to combat contention issues without creating extra or false predecessor/successor relationships. The D-series, ESP-DE, doesn’t have this parameter. Once we realized how much we were leveraging this feature on the mainframe version, and that we wouldn’t have it on ESP-DE, we were a little disappointed. I’m not sure how much of an undertaking it would be to have it added to ESP-DE, but it would be very beneficial to us, as well as other DE clients that I spoke with at Ca World. Hopefully this could be added to the next release of DE and we could get it in before we go totally live in production with DE early this summer.

The secure SimLib/password feature from Autosys I was referencing gave us the ability to hide/secure environment variables by storing them on a totally different server in which security could be controlled. Once the job ran that used the environment variable, or database password, a developer or operator couldn’t see the environment variable/database password resolved in the spool file. Basically what we’re looking for is the ability to store database passwords or environment variables, on or in ESP, without them being seen by a developer or operator. We don’t want anyone to see the resolved environment variables in the spool file or to have to store them on the server. Currently we’re having to store these environment variables on the server, which isn’t a permanent solution according to our Security Admins.

It seems stable, as far as I know. It's been around for awhile, so it's a good product. From our testing, it's been fine. We have a failover situation as well that we've tested; so it's worked fine for us.

We don't have any problems with scalability either. That seems to be fine for us.

Initial setup was fairly straightforward. Well, the biggest thing was that we were already using Workload Automation ESP for mainframe; so we just took that and moved it to the distributed engine, or to the DE series. There are a lot of similarities between the two.

We compared CA Workload Automation with IBM, as well as BMC. We went with CA because we really like the interface, and the way it worked with our products that we already had in house. We did have a bunch of other CA products, and it seemed to tie in pretty well with those.

It just depends on what they're coming from. If they're coming from the mainframe flavor, just know that they are similar, but there are still some very glaring differences that you have to accommodate to.

The flexibility of being able to schedule the timing and frequency of different automation scripts makes it easier for us to meet our customers’ business requirements.

We use the WCC, which is an interface that sits on top of the application. That is pretty user friendly in terms of being able to see the status of job flows, job failures; and in the ability to manually intervene and fix issues. Essentially, the code you're running sends a return code, which you can configure to be read as a success or failure.

We're in healthcare. We need a way to automate loading the members and processing claims. Without a tool, we wouldn't be able to do that efficiently. It increased efficiency.

The most important thing is that duration is not displayed in the actual WCC GUI. I know they have some different add-on tools where you can get that information; but it would be nice to be able to see how long jobs ran, and the history for more than ten days. As is, the scheduler already starts to have performance issues when you keep the ten day history. So there are efficiency issues related to being able to keep more logs.

There are always issues with software. They have some improvements they can make. The way they're heading, I think they're on the right track.

Stability has been good since we took release 11.36. Before that, we had release 11.35. That was somewhat stable. We had growing pains because we switched over from a different scheduling tool.

It has been easily scalable. CA helped us build the Workload Automation infrastructure that we knew we were going to grow into. It was really a partnership between the two of us to make sure we were scaled correctly. We do about 10,000 jobs a week, a couple hundred thousand a month.

Early in my career, I was more on the technical side. Now that I've transitioned to management, I step in at times to help with it, but not as much.

The few times that I get involved, it's usually bad because it's an escalated incident of some sort. I think primarily my team's happy with the support they get from the resources that have been engaged; and works with them through the issues.

We were using Tidal Enterprise Scheduler. We switched over, and then had some growing pains during the transition.

My team owns setting it up, configuring it, supporting it, and all of those things.
The first time we set it up, it was a little overwhelming because it's something different and new. I had a newer resource on it, and there was a time constraint for getting it installed. We had somebody from CA handhold us through the process.

A couple of our customers use Control M, so we considered that as well, from what I understand.

Do your homework, and be ready for a challenge. Anytime you switch tools, it's going to be a challenge.

The ease of using the scheduling feature of CA Workload Automation ESP Edition for Mainframe is valuable to us. Also, being able to configure dependencies and trigger file related processing is a big thing for us. We're starting to get into some of the DB2 plugins as well. We just keep adding functions and learning more.

It has streamlined our scheduling and cut down our overall run time; not in half, but significantly. It's really been great.

We Received a 'Not active. "Scan Failed"; "The 'path/file' does not exist or not a directory" error message/email on one of our event level file triggers. Both clusters were down due to maintenance resulting in this error message. In order to make this active, we had to manually suspend and resume the event. We are requesting an automated process where no manual intervention is needed to make those event level FT's active again and/or preventing that error.
I’d like to have the ability to restart a failed file scan on the mainframe.

Stability has been very good.

Technical support has been great. They've always helped out. Even if it took a couple weeks or a month, they've always come back with a solution.

Our company was using a mainframe scheduler that didn't connect to the distributed systems. We were porting to Windows and we needed a job scheduler that was Windows compatible. I'm not sure what other tools management looked at, but I know this was the best solution.

When working with a vendor, I evaluate their helpfulness and the quality of their technical support. Also important is the ease of contacting them and getting an answer back.

For initial setup, we had a CA team there for several weeks ahead of time. Anything is a little complex when you're going from a tool you've been using to a brand new tool. We learned a lot from them, but once we reached a few months out after the initial setup, we learned much more. There was a steep learning curve. But, it's been a great product. It's better than the previous product. Our needs were expanding, so it was where we needed to go. It has been great.

Give it a try and call me if you need. I'm open to questions and helping. It's been a great workload automation tool for us.

Some of the features I like are:

• Ability to monitor a complex workload
• Easily see our batch flow status
• Deal with problems before they become bigger issues

As an example, we had a stuck file watcher we weren't aware of. Due to the alerts, we were able to reach out and get the file in time to still make our batch commitments. This happened instead of missing an SLA.

I think having visibility has improved things. Our managers can see what's going on as well. It's not just a single technician that's a bottleneck trying to find out where we are. Visibility into the workflow and ease of use to be able to schedule have improved our organization. I'm happy with this solution.

The main push is the web UI. We want to be able to give it to our business users. They don't want to have to log on to a mainframe to use the product. I would like to use iDash. If we can get iDash into ESP, it would be great, even though it first has to go to the DEs before it comes to us. That would be a big improvement. This is an option that we'd like to see.

No problems with scalability. That's actually one of the competitive advantages with this product - the scalability and its ability to do the throughput we need without having any delays. We have scaled as far as we can grow. I've been talking to other companies that are much larger. I'm confident it could scale if we had a tenfold growth and we'd still be okay.

I have not used technical support. Other people in my area have. They seem easy to work with. You know, get the documentation to them; they get back to you in a couple days with what they found.

We were using CA Scheduler Job Management and I think they ended support. I wasn't high enough up to be involved in the decision making process. By the time this solution rolled out, I was happy with how I was able to get up to speed in the product, and support what I needed to support. But I was not involved in evaluating other products.

When looking for a vendor, I suggest looking for long-term relationships, a partnership. You want a vendor who is willing to grow, willing to listen to feedback, offers support, and help us do our job. Make sure you partner with them. Get buy-in from your business units before implementing. I think that's one of the biggest things to success, is let CA get the buy-in for you if you don't feel comfortable doing it yourself. Let CA explain their own product. Get the buy-in first, then move forward so you don't have the resentment of the business units thinking you forced the solution upon them.

• Top-notch scheduling features and functionality
• Reliability, performance and stability
• Advanced GUI to manage the batch, flexibility to schedule jobs on various business needs

• Improved batch processing with PROD monitoring to take corrective actions on batch issues
• Implemented scheduling predecessors/successors conditions

I would like to see advancement in predictive analysis, trending and reporting.

I have used it for 20+ years.

I have not encountered any stability issues.

I have not encountered any scalability issues.

Technical support is excellent.

We previously used a different solution. We consolidated into a strategic scheduling product because it is easier to manage and operate.

Initial setup is complex. It requires technical skills in various flavors of distributed/enterprise H/W, S/W, databases to implement, configure and develop high-availability options.

Review licensing calculation is based on criteria. I recommend not to license based on the number of jobs.

We evaluated other options, including Maestro, CA7, and Control M, to name a few.

Look for industry trends, overall deployment, scale and scope, features and functionality and vendor support structure/relationship.