Control-M Reviews

We are mainly scheduling jobs on Linux Windows, SAP, and DataStage environments; a few other application integrations, like Micro Focus, and third-party applications, like Web API.

We are using it for banking and financial services.

We use Control-M as part of our DevOps automation toolchains and leverage its “as-code” interfaces for developers on a few JSON-based script applications. This is in the testing phase, but in production for one or two applications, and rolling out new applications and application updates is much faster. Earlier, we had to go through a lot of processes. We had to raise a change request and work through various approvals, then the scheduling team would do it and there would be a lot of failures. Now, they are directly creating those jobs and submitting them. It is coming in automatically because it is running in Control-M.

Multiple critical processes have been automated. Here are two of those processes:

1. Our critical banking application for end users, especially to check their bank data, e.g., how much is in their account, how much money they have withdrawn, etc. 
2. It is used for ATM withdrawals and runtime data, e.g., SMSes go out with how much has been debited or credited in their account.

Automating these processes provides more visibility to our application team. They can see critical jobs failing and immediately taking action in Batch Impact Manager (BIM) with the help of our team.

The most beneficial features are the Forecast option and Archiving feature, as well as the integration option with other applications and tools to the API. When it comes to the API integration with any third-party tool, we can integrate using the application integrator tool and API interface with web APIs, which is the best part. Control-M has its own Forecast solution. Therefore, we can forecast how many jobs are going to run, on which day, and at what time. Another benefit is the tool's Archiving feature. So, we had a lot of requirements, like when an application or end user team would say that they want to see the log or output of the job from two or three months before. So, the archive solution is very helpful because we can keep at least a year's worth of data for our environment.

It has a very good GUI. We can search for a job very easily. The web interface, user account creation, and access control are very good. From an access control point of view, we can provide access to as many users as we want. A second group of users can be given a certain number of features, according to the requirements. The web interface is very easy for end users to login and use. A lot of features have been added, e.g., adding jobs. They can add jobs to their stuff, whatever they want, then get it validated by the scheduling team and work it into production.

A lot of businesses are using ServiceNow, which is another tool. I would like there to be some integration with ServiceNow or other third-party tools as well as have easily available integrations. Right now, we need to write scripts. Apart from that, if there were some integrations with an ITSM tool, then that would be good. Because at the end of the day, most of our clients are using different ITSM tools. I know that BMC Remedy is easy to integrate with Control-M. However, if there was availability for Jira as well as other ITSM and DevOps tools, that would be a good improvement.

I have been using it for almost 12 years.

It is very stable. If we are using agents, it runs without any issues. I have sometimes found issues when we are running it with an agentless solution. However, with the agent, it does not have many issues. It will have an issue once or twice a year.

It is a very scalable solution. 

Almost all our end user application teams are using it. 

For day-to-day administration, we have two people. For scheduling, we have four people. 

The integrated guides and how-to videos in the solution’s web interface is a good approach. There are a lot of documents and webinars. Also, the support is very good. We receive good responses very quickly.

I would rate the technical support as nine out of 10.

We migrated from Tidal Automation. In Tidal Automation, various options are not there. So, jobs are running mostly using an admin account. When all jobs are running using an admin account, that is a risk. However, in Control-M, we have various options. We can use an admin account as well as a separate account, like a user account, to run jobs. Whereas, these features were missing in our previous tool. 

We switched from Tidal to Control-M because the application team wanted more control. There is a web-based solution for Tidal, but all the data is shown there. For example, if there are 10 applications, then the web applications team can see all 10 applications, though they might only want one application. Even if the backup team wants to view just their backup jobs, they see all the applications that are working. However, in Control-M, we can control whatever applications that we want, limiting what can be seen by each team. 

The initial setup was easy. BMC provided all the documentation before starting. They did it in the development environment and targeted various applications. They showed us what they were doing before they implemented it. So, we were coordinating with them.

Deployment took three months.

I was involved during the initial setup. It was done by BMC's professional services team and I was part of the support.

It is a good investment. I think we are paying the same amount of money for Control-M that we were paying for Tidal and not getting as many features.

Control-M has helped us achieve faster issue resolution. It is 60% to 70% faster than what was happening before.

Service Level Operations have improved in the sense that fewer team members are required as compared to before. So, we had a bigger team, and that has been reduced because of Control-M's latest features, like development. Therefore, a lot of things are now being done by the application team instead of having a separate scheduling team, which has now been reduced. The application team is currently being trained to handle more things on their own. They also have visibility on what jobs are running and what jobs are failing.

In our environment, pricing depends on the total number of maximum jobs that can run, which is fine. Therefore, if the number of jobs increases, then the licensing fees will increase.

I have hands-on experience with Redwood and ActiveBatch solutions. If there are a lot of Windows requirements with Windows jobs, then definitely ActiveBatch is the best solution. If we see there are a lot of SAP-based requirements, then Redwood is the best solution and either Redwood RunMyJob or Redwood CPS work for this. If we see Unix or any other application with jobs, then Control M is the best solution.

While we do use Control-M to streamline our data, we don't use it much to view our data and analytics project since there are various third-party applications of the bank where jobs are running. The major work that we do is creating and adding those jobs to the tool.

We are not using file transfer at all because we are a US-based financial company. They have a lot of restrictions for file transfer between third-parties, so Control-M is not used for file transfers.

It is one of the best scheduling tools in the market for batch job automation and DevOps.

I would rate Control-M as nine out of 10.

It provides enterprise scheduling for a lot of things, e.g., supply chain, payroll, reporting, sales and marketing, and web services, which is our online store and ordering.

We are currently running jobs on Control-M for databases, web apps, proprietary applications, Workday, Oracle, WebSphere, Kafka, and Informatica stuff on Unix and Linux. It is flexible. I haven't had any problems with compatibility.

It used to be on-prem, but now it is in a different data center in a different city. So, it is a VM.

We use the GUI, but there is a web interface that some users are using on the business side. Those users can easily check on their job flows on the web interface, so they can see whether their job has completed or it is waiting for something. It can check the status and  history of what happened, for example, the previous day.

The scheduling is quite easy to use and pretty robust.

Control-M provides us with a unified view, where we can easily define, orchestrate, and monitor all our application workflows and data pipelines. It also provides the ability to filter. So, if I don't want to see everything, I can also narrow it down or open ViewPoint. This is very important since we have thousands of jobs to monitor. If we did not have this ability, it would be very difficult to see what is going on.

It is easy to use, and you can set things up very quickly. We can copy jobs, making copies of the existing configurations and setup. 

Control-M reporting is a bit of a pain point right now. Control-M doesn't have robust reporting. I would like to see better reporting options. I would like to be able to pull charts or statistics that look nicer. Right now, we can pull some data, but it is kind of choppy. It would be nicer to have enterprise-level reporting that you can present to managers.

I have been using Control-M for at least 12 years.

I haven't seen any significant issues with Control-M in several years, e.g., we haven't had to call support. So, it has been very stable.

It runs all the time. We are running thousands of jobs with little issue, especially when I compare it to some of the other systems that we use for other things. It has been very stable.

One to two people are needed for day-to-day administration. I usually do it myself.

I haven't seen any problems with scalability in terms of performance or stability. 

There are at least 50 people using Control-M. Some of them would be architects, senior programmer analysts, database administrators, Unix administrators, software engineers, and team leads.

I had an issue one time at my previous company. There was some issue with the database. We worked with Level 2 support to fix it. Other than that, there is not too much to talk about really in terms of problems. 

The integrated guides and how-to videos are very good in the solution’s web interface for reducing the time to full productivity with Control-M. BMC puts out a lot of webinars and videos on their YouTube channel. Sometimes I do use those. I go in and watch the video or webinar to see what is new or how to do things, which is very valuable.

We migrated from CA Unicenter, which was out of service and quite clunky. That system didn't have a graphical user interface; it was command line-based. It had a console, so it was very difficult to see what was going on. It was also difficult to troubleshoot. It took a long time to find information or set things up. Therefore, management decided to move to Control-M, especially since I had experience with it. It has been much easier to use and work with than CA Unicenter.

CA didn't have File Watchers. It had another way of achieving that outcome, but it was very cumbersome and not always reliable. It was also difficult to troubleshoot. 

There is a lot of logic in Control-M that you can do. For example, after a job completes, there are actions you can do. There are actions before the job completes or before it starts. There are actions you can do afterwards. There was some logic that you can add to the job, and we just didn't have it with CA.

The calendars are also a lot easier to work with using Control-M. The CA calendars were just terrible. In Control-M, we have a lot less calendars, about 20 calendars, compared to 80 or 100 in CA.

It is faster to implement things like new jobs or projects with Control-M. Whereas, in the past, certain things would be executed manually, like scripts and workflows. It is very easy to use. I can set up jobs and workflows quickly, which helps developers to test.

It is very easy to set up a PoC. If someone just wants to do a quick test, it is very easy to do. Assuming that everything is in place, it is quite easy to test or set up cyclic jobs.

We did the setup twice. The first time was a migration from another system, which was not BMC. That took three months, which was still pretty fast, and it was very successful. The second time was an upgrade to version 19, and that took about two months, and it was also quite successful. From my perspective, the solution was very good as far as upgrades go. We didn't have any major issues, before or after the upgrade.

We had a vendor help us out, but overall it was very smooth and a success. We used Control-M’s Conversion Tool when migrating from CA Unicenter to Control-M and the vendor helped us. Using the Conversion Tool was very important because it speeded up the process. It took all the information from one system and transferred it over, which saved us a lot of time. So, we spent more time on the verification. We spent less time on the setup and spent more time just verifying the setup to make sure everything was correct. It was a time saver for us.

My experience with BMC during our initial deployments and upgrades was very good. I got quick responses with good information. The people that I dealt with were knowledgeable and helped to resolve the problems. So, my experience was very positive. I would rate them as 10 out of 10. I never had any issues.

Control-M has helped us achieve three times faster issue resolution. We have it integrated with ServiceNow, so it tickets automatically. Whereas, in the past, we used to do it manually. We had operators opening tickets, so it speeds up ticket resolution for opening and assigning a ticket. Also, Control-M captures some errors. Sometimes, this helps to troubleshoot any problems. You can set up alerts for jobs that run too long, etc. So, it has a lot of features that we use.

Control-M helped us double or triple our Service Level Operations performance.

CA sent us a proposal and IBM also sent one for Tivoli Workload Scheduler. We saw their presentations and packages, then did some research. We thought Control-M was the best solution based on experience and feedback from others. I had experience on Control-M already. I had been working on it for several years and had a positive experience. The other thing was just ease of use. Tivoli and Unicenter just do not seem as polished. They didn't look as easy to use, especially Tivoli. I think we heard that Tivoli was very clunky and not easy to use.

It was mostly my experience with it. Control-M was easy to use, very stable with no issues, and easy to configure and maintain. Whereas, CA was not as easy to use nor polished. CA also always keeps on buying other companies and incorporating things, so the experience is not as smooth. With Tivoli, we just heard that it was terrible to use and lacked a good interface. We had another Tivoli product from IBM for backups, and it was just terrible.

Give Control-M a chance. If somebody is considering the solution, they should install a demo on their system and use it. It is very easy to use. It has a lot of options and features. BMC is pretty good when it comes to upgrades and implementing new features, so there is always stuff coming in. There are a lot of new options that we haven't even tried.

Of course, you should compare all your options, but Control-M is a good choice. It is probably the best.

In the future, we will probably use Control-M as part of our DevOps automation toolchains and leverage its “as-code” interfaces for developers.

I would rate it as nine out of 10. The reporting is something I would like to see improved. Other than that, there is not much I dislike about it. I work with it every day. I have been working with it for the last dozen years or so. It is an excellent product. It just needs more reporting.

We use Control-M to monitor jobs on the endpoints. We monitor throughout the day to see which jobs fail. It helps resolve issues with the programmers. They know if they want to rerun, force complete, or hold a job. We work hand in hand with the programmers who have the final say on what they want to do with a particular job that requires action. Control-M is deployed across multiple locations, but I can't estimate the number of users.

Control-M is a critical part of our operations. We rely on it to do our jobs daily. It helps us automate things that come from the JCL side where you would normally have to do everything manually. It's a little quicker and more automated on the BMC side, which makes things smoother for the end-users. 

The solution allows you to relay your issues to management, who in turn, can communicate them to our customers and programmers. It maintains a dialogue between all parties. It's had an overall positive impact on our process execution. 

We can set up automated email notifications to the programmers or the whole team for a particular job. It helps save time because we're not consistently looking at the job to see if it has ended or failed.

The Control-M interface makes delivering files in our data pipeline a little easier. The integration is so much more seamless, so the transition is a smoother experience.

I've been using Control-M for four years. 

The stability is fairly good. We haven't had any serious issues. 

The response time could be faster when you need a person to answer your questions. There are situations where availability becomes crucial. 

I wasn't involved in the deployment. Maintenance is handled by our unit team. They do updates and patching almost weekly.

I rate Control-M an eight out of ten. It comes down to preference and what you need. There are multiple platforms out there, but I've only used this software.  I recommend doing some research and seeking out a lot of opinions. Talk to other folks who worked with other solutions to get a grip and a better understanding. 

Overall, we have a great visual of all of our key business processes, and it gives us a secure way of transferring everything in and out of the business so that if anything were to be intercepted, it would be secure and not compromised.

We transfer financial files between Google cloud. We use it for the I series. We have a lot of automated jobs, around 3,000 jobs per day, that we load that range between just regular commands for our planning allocations, finance, or data warehouse along with Google cloud. We're starting to implement a lot of that, but a lot of it has been automated and it allows us to process everything in a timely manner.

We are in the process of implementing the managed file transfer which gives us the dashboard, but we are still fine-tuning that. Overall, it does give us a great picture and helps everything. If there's something delayed, it gives us the opportunity to send out a notification to a team to say that their process is delayed. We get tickets created and have everything sorted in a timely manner.

We use Control-M's web. It makes it very easy for us to show them what they need to see and what they don't need to see. They mainly can just view the tasks that they have, but it's pretty divvied up permission-wise.

Control-M integrates file transfers within our application workflows. It has made everything a lot quicker. We've been able to get files transferred to vendors and we've been able to retrieve files from vendors rapidly and securely.

It also streamlines our data and analytics project. Mainly developers will create either different types of processes that we will implement within Control-M to make it automated and that definitely, I would imagine, helps streamline and format certain projects and reports that we send out to executives that helps out a lot. I don't know the exact extent of it, but I would imagine that it has helped our business service delivery. 

It has helped to achieve faster issue resolution. With the shouts and notifications that we get, we're able to create tickets as soon as a problem surfaces. So as soon as we do get a job failure, we get an email notification that prompts us to create a ticket, page out the team, and get it resolved in a matter of our terms of our SLA.

The most valuable features are the Advanced File Transfer and the managed file transfer. They make transferring files securely seamless. It's very easy to set up, get deployed, and have it transferred to and from vendors. As long as we can get our firewall rules implemented at a decent time, it's very easy and seamless to get important files transferred in a secure manner.

Control-M has automated critical processes. We run a lot of our backups through Control-M, daily sales reporting, and warehouse initiatives with shipping and planning. There are a bunch of finance processes that go through here that are time-critical. It's made everything more streamlined and secure and it comes through much quicker than doing it manually.

We have had a few small bugs with the configuration of the different types of jobs where it is the order of operations if it's doing a statement, we've noticed that if you try and do a little bit of both, it may cause one of them not to work. 

We've also had a few database bugs within our organization. I think we are migrating to OpenJDK rather than just regular Java and that has since shown some issues with our Control-M instance, timing out and causing our jobs to stop running. We are still working with BMC to fine-tune that and get that resolved.

I believe the file transfer process does everything that it needs to do. I don't believe that there's anything that would need to be changed there with all the features that it has, it's pretty robust. But overall I don't really see many changes that we would need.

I have been using Control-M for three to four years. 

Other than the database connections that we've had and as of, I believe when we upgraded or moved away from Java using OpenJDK, it's been hit or miss. I know that we've had a few instances where our jobs just stopped processing, but we're not sure if that's related to the application itself or if that's something in our environment, but overall I am personally okay with the way that it runs.

We run it on windows as well as Linux, and we are still trying to work on getting it to our DR site. But, I believe we are able to process quite a bit through there.

We use it for our I series AS 400. We also use it for Google Cloud, Cognos, ADP, many custom applications that we run as well, but we do a lot of I series.

I do not plan to expand it to other applications in the future.

My department consists of eight people, and we are mainly data center analysts. I'm their manager. We also have developers with a select few developers that are able to get in and view it, but they cannot actually create anything. They can just view and see what is running.

Between five to 10 users are responsible for the day-to-day administration of Control-M.

I've never used Control-M before, prior to being here and all I had to use were the help guides from the web, as well as the user interface that we have. The help administration guide has been the only way that we are able to get questions resolved and to go through support.

Their support is hit or miss. We have had successful sessions with them. And then we have other ones where there are fingers being pointed and it doesn't really solve anything. We have a rep that my manager goes through, but we seem to usually get issues resolved in a timely manner.

We have seen ROI. We were able to have fewer people manually running tasks. We're able to put them right into here and we're able to scale and move a lot of file transfers through here.

It is a little bit expensive. I believe that however we are set up, it might be per job that we load or the highest number of jobs that are loaded monthly and I believe it is quite expensive.

My advice would be to try and utilize as many features as you can. Don't get overly creative with things because that can just confuse other people. If there are other users getting in there, you want to definitely have a standard workflow on how jobs should be created, organized, and make sure that you keep track of what's being changed so that if something were to fail it's easily trackable.

It's a very robust application and there is a lot that can be sent to it and sent out of it and you do not want it to get into the wrong hands because you can do quite a bit with it.

I would rate Control-M an eight out of ten. 

The major use cases we have are batch processing and MFT. We are heavy users of the MFT plugin.

One of the benefits of Control-M is that it's helping to give business users visibility into and control over their jobs, and freeing up IT personnel to focus on other operations. Here, I'm mainly thinking of MFT. Our MFT end-users did not have access to our prior MFT tools at all, so they couldn't see the jobs. They would just request a job be built and then we would publish job reports so that they could see what was out there. Now, in Control-M, we're able to give them job-control access. We still lock down the building of file transfer jobs, but they now have the ability to see a job and see how it's built. They can run a job and hold a job if they need to.

But even for some of the batch jobs, we've written some orderable services that are allowing them to run jobs on-demand, jobs that they used to have to log in to a server and go through a menu to do. Our business users definitely have much higher capabilities in our product now.

And while we are primarily on virtual servers, we are in the process of standing up some agents in the cloud. We have our first agent in AWS up and we're getting ready to do some testing on it. That's pretty critical. There's a really big push within our organization to move into cloud. A lot of our next-gen apps that are going to be replacing the current ones are being built in the cloud. We have that first agent out there, but I assume there are going to be many more to follow as these new applications are stood up in the public cloud. Today we're on-prem, but I definitely envision us moving the entire Control-M stack to the cloud. Eventually, it will be in the cloud and we'll just have a couple of agents on-prem, versus being on-prem and having just a couple of agents in the cloud.

Control-M has also helped to make it easier to create, integrate, and automate data pipelines across on-premises and cloud technologies. It's due to the ability to orchestrate between workflows that are running in the cloud and workflows that are running on-prem. It gives us the ability to have end-to-end workflows, no matter where they're running.

The automation is one of the most valuable features.

New plugins could be tested better. We've had a lot of problems with the MFT plugin. We've been working through a lot of issues with BMC on it.

The functionality that has existed for long periods is very stable. But the problems with the MFT plugin specifically, and problems we've had with MFT in general, have unfortunately caused the entire stack to be affected enough that our end-users couldn't even log in to the application. 

I wish we would have known better about how MFT impacts the application as a whole, and I wish they would have done more load testing around that. That seems to be where most of our issues have been. The issues have been so bad sometimes that the entire app goes down, not just MFT.

I've been using Control-M for about two and a half years.

The stability of Control-M has Not been great. A big thing we've been trying to work on with BMC is observability. Modern applications should be observable and resilient, but we're finding that sometimes Control-M is not very resilient and many times Control-M is not very observable. We're working with BMC to try and figure out how we can externally monitor this application. 

We are using Dynatrace because of the problems we've had with Control-M. If we stood up Control-M and never had any problems, we probably wouldn't be too worried about being able to observe the processes and the queues and the communication between processes. But because we've had so many problems, it has forced us to dig in. We can't wait for a problem to happen and wait for a week for support to tell us how to fix it. We can't do that in a production environment. We have to know before a problem happens so that we can be proactive and not reactive. That's been a big struggle that we're continuing to work with BMC on.

It's pretty scalable. You can stand up a ton of agents and you can stand up a ton of servers, if you need scheduling servers. Scheduling and agents are definitely very scalable.

There isn't the ability to really scale the EM (Enterprise Manager) a ton, although the GUI can be scaled somewhat. I don't know how much of a need there is to be able to scale the EM. We don't seem to have issues on the EM side, for the most part.

We're definitely having issues with the gateway between the EM and the scheduling server, but BMC is telling us that it's because we're running too many file transfers on the scheduling server. They say that if we stand up more scheduling servers, that should resolve that issue. We'll see if it does, if we still have any issues after we spread the load of MFT, not only over more agents, but also over more schedulers. If we still have issues after that, I think that would mean you're pretty limited in how you can scale your EM. That is the one thing about which I'm not sure how well it scales.

Technical support is very back-and-forth. That's one of my gripes about the support. We open a case, they ask us for logs, we upload logs, and they come back and ask us for something else. 

At times, there isn't a lot of what I would call working together with them. We do now, but that's because we had a ton of support cases piling up and we started escalating with their internal leadership. Now, there are weekly meetings between our leadership and their leadership and our account managers, as well as weekly meetings with the support team and the dev team, to talk through our cases and any updates on them.

It took a lot of pushing from our end to get them to work with us. Otherwise, they just asked for logs and then we were waiting for a couple of days for them to look through all the logs and get back to us. We can't be doing that, especially if the issue is a production problem. We can't just upload logs every time we open a case and wait around for two weeks to get an answer.

Another gripe is that they're very siloed in what they know. Something that I've been asking for for a long time, from BMC, is somebody who can take a look at our environment as a whole, and not just in pieces. Every time we open a case with support, they want to assign it to a specific area. If it's a problem with the agent, then an agent person will look at it. If it's a problem with the EM, then an EM person will look at it. But nobody is looking at the environment as a whole. That's an issue because a lot of our problems, as I've mentioned, with MFT, are impacting the entire environment. It's not just one component. It's the entire environment and how those components relate and how they communicate that have been impacted. Nobody has really looked at the environment as a whole, in support. I think it would benefit BMC to have more experts on the entire application and not have everybody so siloed.

Neutral

The initial setup was a little complex, due to some of the requirements. It requires that you have C shell as it doesn't work with the regular BASH shell. There are some old mainframe requirements that have carried through the product, even though we don't run it on mainframes. For example, the user that you use to run it has to be under seven characters long. We had to modify the account we use because the name was too long.

We're still really trying to get our environment squared away. We started two and a half years ago, but we've got a laundry list of applications that we're migrating out of and we've only completed one of those migrations. We're having to modify our architecture now because of the load that we are running. I'm working with professional services at BMC to review our existing architecture so that they can give us a BMC-supported design recommendation.

One of the competitors we are migrating from is Broadcom/CA. Broadcom bought a couple of products. They own both AutoSys and Automic, and we are migrating out of both of those solutions. AutoSys has been pretty straightforward to migrate into Control-M because the job configuration is pretty simple. However, the Automic workflows are very complex. They utilize certain features that only Automic offers, things that we can't replicate in Control-M. That is causing a lot of issues and has caused us to put that project on hold for the time being, until we can work through some of the problems that are being presented. We've been migrating Broadcom for at least a year now.

Some applications are pretty straightforward. MOVEit is an example of one that's a pretty straightforward conversion. However, another tool we have, Diplomat MFT, has a backup file structure that is not what the conversion tool was expecting. We ended up writing a custom Python script to do that conversion for us. The ease of migration really depends on what application you're migrating out of. It could be very complex or very easy.

The migration process is a very high concern. We selected Control-M due to the ability to migrate everything into it and have everything in one tool. If we can't get our migrations completed, then Control-M will just be another tool on top of all the other ones that we have to support.

We used VPMA for the deployment. Our experience with them went pretty well. They're definitely very knowledgeable about the product

I don't know that they, or really, as I said earlier, even BMC had all the knowledge around how MFT could impact the application as a whole, back when we originally bought this. MFT was very new back then. VPMA did their best and guided us as much as they could, but I just don't think the plugin for MFT, specifically, was very mature yet. There were probably a lot of unknowns there.

We had a pre-sales team from BMC that helped us in the very beginning, before we worked with VPMA. They were nice, but I wouldn't say they were very knowledgeable. They had a very surface-level knowledge of the application. They didn't know anything that was deep. They would have to find out for us and get back to us.

It's not my realm, but I would assume Control-M has not helped us realize any savings on renewal costs after switching from Broadcom. The cost of an agent is significantly higher for Control-M than it is for Automic or AutoSys.

We are paying way more for Control-M than we've paid for any of our other scheduling tools. We have an inside joke that Control-M is sold as the "Bentley" of schedulers, but we feel that we got a "Pontiac" because it's falling apart half of the time.

BMC has two licensing models. One is where you pay by job execution and the other is where you pay by endpoints. I'm sure the specifics vary depending on the customer, but we opted to go with endpoint licensing. I'm not sure if that was the best decision, knowing what we know now.

With endpoint licensing, we pay per server. That means it behooves us to run as many jobs as we can on each of those servers. But we're very much finding that even if we make those servers very large and give them a ton of resources, they're still not able to perform because Control-M doesn't scale very well vertically. If you make the agent bigger, if you double the CPU and RAM, that doesn't necessarily mean you can run twice as many jobs. It's going to choke in other areas. 

We will see if we end up switching our licensing model. I think the endpoint licensing model we chose is quite a bit more expensive than an equivalent model where we would pay per execution. We would definitely have to change a lot about our environment if we were to change our licensing model from endpoint to execution, because today we give all of our end-users the ability to run jobs on-demand. If we were to change our licensing model to be based on executions, we would probably want to restrict that a little. 

The way you license is a very large consideration when moving to Control-M.

We really haven't taken advantage of some of the features that Control-M offers yet. The main thing I'm thinking of is SLA management. We haven't implemented that yet on a lot of our business-critical workflows because we just lifted and shifted everything into Control-M from the old app. As of today, things are pretty much equal until we are able to implement some of those additional features.

There are capabilities that Control-M offers that are good and I can see it being a very good product. BMC, as a company, has some maturing it needs to do in a lot of its processes. They have a very good sales team, but a lot of things after that can use some work.

We definitely haven't bailed on it, but I've heard a little bit, back and forth, from people at BMC that they might not be too upset if they lost us as a customer because we've been having so many problems. We've been on them about helping us get this environment corrected and functioning as we expect it to. But in a year from now, it's possible we could be in a really good place. I'm excited to see where it all goes.

Most of my work goes through Control-M, e.g., all my development work. When it goes to production, it moves to batches. This will be either daily or monthly batches.

There are many applications running in Control-M, e.g., a quantitative risk management ALM application.

Most of our production jobs at the organization level are fixed through Control-M, running as either mainframe jobs, Informatica jobs, or QRM software-related jobs. Also, file sharing through FTP jobs and dependency setups between different software patches all run through Control-M.

We use file transfer jobs in our workflows. For example, if I want to share reports to end users in the production shared area, where specific users have access, Control-M makes this very easy as soon as a job is complete. The FTP job copies the report to a defined shared area, triggering an email to the user with a link. As soon as users are notified through email, they can open the email and click on the shared link to view the reports.

We have automated critical processes with Control-M. Our report deliveries are now automated. We automated our batch jobs and can check our dependencies through Control-M with minimal manual intervention. This has saved a lot of time and manual mistakes. For example, we used to copy old reports and send them via email, then users would come back to us, saying, "These are not this month's reports. These are old reports." After automating these reports with Control-M, there were no errors at all.

Multiple software can be collaborated through Control-M, then we can seamlessly monitor when it goes into production after a scheduled daily or monthly deployment. Even though we don't have any privileges to change these jobs, we can monitor them with read access and see how they are being executed. We can also verify their dependencies and see the logs. If there are any failures, we can get the logs from Control-M and fix them in the development environment, in the cases that are required to be done as soon as possible. It provides a complete picture about how the batches are running in production.

We have a lot of things that need to be considered. Everything needs to be done one after another in Control-M, where it provides us a pictorial representation of job dependencies, and even a person without technical knowledge can understand it by looking at the pictorial representation of jobs. So, we can provide the exact time when it can start. Then, we can update the users about the expected time for the job's completion. In case of any delays, we can understand them, then provide a new ETA to the users. Without Control-M, it would be difficult to provide these estimates.

We are using the web interface. We are not going through the mobile because we are a bank. Everything we do is through our laptops, not through a mobile. The web interface supports our business initiatives well. Whenever we want to see the updates, we need to connect to Control-M. We know what needs to be monitored and verify them depending on what their dependencies are. If the batch is still running, we can understand the historical information, then calculate and provide an ETA to users.

After we complete FTP jobs, those FTP jobs will be cleared from the Control-M schedule after the noon refresh. So, I struggle to find out where those jobs are saved. Then, we need to request execution of the FTP jobs again. If there could be an option to show the logs, which have been previously completed, that would help us. I can find all other job logs from the server side, but FTP job logs. Maybe I am missing the feature, or if it is not there, it could be added.

When integrating different projects through Control-M, sometimes dependencies cannot be identified. 

I have been using Control-M for almost six years.

I have never faced any issues with stability. It is very good.

10 to 20 people are administering it.

I have never faced any issues with its scalability.

500 to 600 people are actively using Control-M. These are business analysts, team leads, managers, developers, and senior developers. Anyone who is touching the development and production would have access. 

Whenever we have issues, they are resolved through our organization's admin.

With the integrated file transfer feature, most things are automated. Previously:

• We used to copy the report, then send manual emails. However, with this feature, we are able to complete tasks with minimal monitoring because they are automated. Users are automatically notified as soon as the reports are complete. 
• We used to work during the daytime and after business hours. We were forced to open and view that the reports were there. Or, we waited until the next day to copy the reports, sharing and sending them by email. With this feature, we are less bothered. We can wait until the morning of the next day. We just go into the office and see if the reports have been shared already, seeing that everything is okay. So, during the night, some reports are generated and emailed to the users. 

The integrated file transfer feature has saved us a lot of time and manual effort, approximately two to three hours a day. Also, users are notified as soon as the reports are complete, where they used to wait until the next morning. They can just verify their email using the office provider mobile. Then, they connect to their laptops and get the reports. So, if they need the reports and are waiting for them, then they are not required to wait until the next morning to receive them, saving about 10 hours of their time.

I was not involved with the initial setup. That was before my time.

Our data transfers have improved using Control-M processes, e.g., our monthly batches. When we used to do things manually, like copying files and reports, we used to take three to four days to complete a batch. However, with the automated file transfers and report sharing, we have been able to complete a batch within two and a half days and our reports are on time to users. So, 30% to 40% of the execution time has been saved.

Control-M has helped us achieve faster issue resolution. Whenever we come across any data-related errors, instead of going into the process, we just get the Control-M log. Nearly 50% of our issues are resolved by looking at the Control-M logs. 

Control-M has helped us to improve Service Level Operations performance by 30%, because we no longer need to manually copy reports and receive email notifications. So, the process has improved a lot.

Organizations looking for seamless integration with different applications can move forward with Control-M. In my experience, Control-M provides a good solution. It also integrates with different applications and software.

At this point, we are not using the solution's streamlining for data and analytics projects.

I would rate it as eight out of 10.

We are using Control-M mainly to schedule our jobs and also for file transfers. We are now in the process of using Control-M to take some workload off our mainframe. 

We use it mainly for job automation and handling large chunks of data automatically.

We have Informatica workflows, which make up about 50% of all our jobs. Then, we have all kinds of software on Windows and Linux servers. The file transfers are another big thing on Control-M. However, we are mainly using it to automate our in-house scripts, like monitoring and whatever needs to be done.

We mainly use desktop clients. Some users are also on the web. Currently, we don't use the mobile interface at all.

We have some batch jobs or Informatica workflows that create the files for file transfers. We have those on Control-M, so it is all automated and happens through the conditions.

Our daily customers' accounts and credit card actions files are processed by Control-M automations every day. That is pretty much part of the core of our business. Other critical components are some monitoring scripts and health checks on our servers, which are run from Control-M. This has made things easier because we have the Batch Impact Manager on Control-M. So, we can use that to send emails, like, "We haven't received the daily-files yet. Or, the daily files are going to be late." Therefore, we have proactive monitoring if things aren't running on schedule.

I don't think it transfers data any faster than before. However, we now have better control and can also send emails to the correct people directly from Control-M, like, "Hey, this transfer is now complete." In terms of data transfers, and if something goes wrong, it is easy to just rerun the file transfer.

If we are using the Batch Impact Manager, it has caught a few times where the job has been running for a while and may not meet the deadline. There may be a loop somewhere, where one job has been stuck for a few hours. So, in this case, the Batch Impact Manager notifies us that it is taking quite long. There are days that this is useful to locate issues.

Multiple scheduling options allow you to do anything you want, whenever you want, and however you want. You can easily be in control when things happen.

Control-M provides us with a unified view where we can easily define, orchestrate, and monitor all our application workflows and data pipelines. This is quite important because I am our Control-M administrator. So, it is pretty important to me personally, but also for the company. It may not yet be quite in the center of our business, but we are clearly using Control-M as our main scheduling program.

Since we are using version 9.0.18, the web interface is a bit outdated and doesn't really support all our needs. However, we are migrating to 9.0.20, which should give us a lot more options, even in the web interface.

The unifying features between Control-M for different platforms needs improvement. The scheduling options on the Control-M mainframe jobs are different than they are on our Linux server. There are a few differences here and there.

There are capability-related issues between versions, but I think the latest fix pack has that covered. BMC has been doing a pretty good job about this.

I have been Control-M for two and a half years.

The stability is pretty good. We haven't had any issues with Control-M being unstable in the last two years. They are up and running 24/7.

One person is the minimum needed for day-to-day administration of Control-M. We have three admins, who are also our SFTP and file transfer team. Someone just decided that they should be the Control-M admins, so they made all three of us go through the admin classes. Now, we have three admins. 

Scaling has been pretty simple and a straightforward process. We just recently got the Control-M Workload Change Manager, which is an additional plugin to the main software. That installation was also quite easy. We got it up and running pretty quickly.

We have about 10 people using Control-M actively, who are system specialists and business intelligence specialists. We have three admins, then we have some batch job designers from the mainframe team using Control-M. We have also trained some of our Informatica people so they can monitor their own workflows and create new jobs. They can basically do whatever they need to do by themselves. 

I would rate their technical support as five out of five. They have been really helpful and knowledgeable. Even though there have been some cases where support has originally said, "Well, we don't know for now," they have asked for data and provided us with a solution pretty much every time we have had any issues. 

If they don't have a solution on hand, they take it to the lab. We communicate with them and the lab, then everything works out pretty well. Even if there is a big issue, which isn't very common, they have just taken it, and said, "We will see. We will go to the lab where we will test".

The interface guide and YouTube videos have been somewhat useful. However, there is too much data in there. When you try to search something, you get too many search results that weren't exactly what you were looking for.

I don't think anything has changed that much. We used to have CA-7 before Control-M. Now, Control-M is just kind of taking over. So, not much change happened. It is just a new software to do the old job. 

We have benefited from Control-M. It is much easier to use and a bit more versatile than CA-7. 

I personally don't use CA-7 because it is located on the mainframe, and I'm not a mainframe guy.

I wasn't involved in the initial setup of Control-M.

We are currently in the process of upgrading Control-M into a new version. We have been working closely with BMC's technical people. 

So far, I think it has been good. No one has been talking about getting rid of Control-M. It is more like we are increasing our Control-M usage, if anything.

Control-M has improved our service levels on pretty much any aspect. Now, we can see the Control-M estimates of when a certain job will be completed. They become pretty accurate once a job has been running for a week or two. It can predict quite well when a certain job will be ready. So, if a customer asks us, "When are we going to receive our file?" I can check on Control-M, then say, "Well, I would say around...," whatever time it shows and let them know.

We have the CA-7 on the mainframe, and I have seen it being used along with Control-M. Control-M seems to offer a much better user interface, mainly because it is graphic and not on the black screen of a mainframe session.

I don't think our data analysts are currently using Control-M. We do have Informatica software in use, which is some sort of data analyst software.

Always make sure that you have at least double checked everything, because Control-M does everything you tell it to do and exactly as you tell it. Therefore, make sure you are giving the right orders.

Working with Control-M has been pretty complex, but that has been mainly due to our corporate policies since we are located in Finland and in the banking sector. So, there are hundreds of things that we had to consider. While it has been a complex process, it has been more because of our corporate policies rather than Control-M. Once we decided everything, and everything was approved, just taking Control-M into use has been a pretty straightforward process.

Definitely take the scheduler course provided by BMC. That was hugely helpful for all of us. Trying to learn Control-M on your own will be a tough path to walk.

We have Control-M on the mainframe. As the mainframe will be taken down in a few years time, we have to replace the mainframe scheduling agent with something else. That will be Control-M.

Our dev teams are running their own fields. Once they are ready, they go through systems to store into production, then we can automate it. However, during DevOps and other testing phases, we may not use Control-M at all.

I would rate Control-M as a nine out of 10.

We use it for scheduling nightly processing of data.

It has improved our organization a lot. It has helped us control any problems that we have with jobs. We have critical jobs that run and we can tell ahead of time if there's a problem. There are alerts that we can send out. And if a certain job goes down, we can tell what the impact is and which jobs are impacted that are waiting for that job to complete.

We're better able to meet our service level agreements because we do a lot with the Fed. There are certain things we have to have done at a certain time. The automation the product provides means we either meet our or are ahead of our deadlines. In addition, we can tell if a job is running long and if it's going to meet the SLA. And if it's running long we can see why it's running long. That's a benefit for us.

Before, we used to schedule jobs on the servers and we'd have issues with the servers. With Control-M, we can tell if there are any issues coming up because we can run the critical path and see if there are problems before they actually happen. On the server, we couldn't necessarily tell if something wasn't running.

When it comes to creating actionable data, it gives the auditors a very accurate and timely report. Our audit preparation process is much easier. We don't have to do as many manual reports anymore. Previously, it was painful. We had to do everything manually with multiple spreadsheets and it was just ugly. With Control-M, it's all in the database and we just extract the information from the database.

Also, our management team is happy with the orchestration of our data pipelines and workflows. They're happy because they get to see the information through the reports that we create. We're also meeting our service level agreements with the end-users, in terms of getting them their data. And customers are happy because their information is being put into their accounts on time and correctly. 

And for projects, the orchestration of data pipelines is helping because we can go through the testing before we move something into production. That means that when we have a major project or an upgrade coming up, they can run it all through the test, try different scenarios, sign off on it, and then move it into production. It's a very streamlined process. If we didn't have Control-M, our projects would be slower because we'd probably have to be doing a lot of stuff manually.

It's very critical for our business. If we have an outage coming up, for example, if we have to shut down power, we can tell what's going to run and if anything is critical during that time frame. We can manage the data much more easily.

• The reporting facility is very helpful in creating reports for auditing. 
• The FTP function is very easy to use.
• It is simple to create, integrate, and automate data pipelines and to ingest data from different platforms. It integrates well between platforms.
• The Control-M interface is also very easy and very comprehensive. It's pretty simple to navigate through all the different functions.

It's very important for us that Control-M orchestrates all our workflows. And the plugins have enhanced what we already have.

I would like to see more auditing capabilities. Right now, it has the basics and I've been trying to set those up to work with what our auditors are looking for.

I've been using Control-M for 12 years.

It's very stable. We've had no downtime with it. The only time that ever happens is if we have lost the server but that's been very rare.

It's scalable. We use it across multiple states, geographically. We have about 1,600 end-users. 

The technical support is wonderful. I've had no issues with them. Contacting them is very simple, you can do it online. And I usually get a response back within an hour.

Positive

We did not really have a previous solution. We just scheduled tasks on the servers. There was no uniformity.

Our return on investment is that we don't have a lot of downtime anymore. The information that we receive and post to our customers' accounts is quick and there are fewer errors. As a result, we don't get as much feedback from the customers compared to what we used to get.

The pricing is reasonable. It's not an exorbitant amount. The licensing is pretty reasonable for the number of jobs that we run.

The plugins will be an additional cost.

The only maintenance required is due to the updates that come out from BMC. Three people manage that part of it.

If someone said to me they're looking for a process automation solution, but they're concerned that Control-M isn't modern enough to work with multiple cloud-based data sources and tools, I would tell them they can test it. They can physically set up a test function and see the product work for themselves. It wouldn't be a full-on PoC, just a snippet, but they could see the functionality and how things interact. It depends on what they're trying to accomplish too.

My advice is "use it." It's very end-user-friendly. It works, depending on what you're trying to do. All the platforms work very well and it doesn't take a lot to get it up and running. And the help is out there if you need help.

Overall, it's very well done. We go through the AMIGO (Assisted Migration Operation) process, and there's a lot of help out there for Control-M. There's a community as well if we have questions. We really have no complaints. The solution has sped up our process execution.