Control-M Reviews

We primarily use the solution for automation, orchestrating and automating the workloads, and being able to schedule tasks. Prior to Control-M, we were manually running jobs or there was either a scheduled task on Windows, getting Task Scheduler, or we'd have a script laid out that someone would have to run through manually on a daily basis. 

We learned about Control-M and felt that it could take over that process and have it automated, while also providing some monitoring and notifications so that if something did fail, we could easily be notified and keep track of it.

It provides a holistic view of jobs that are scheduled to run. We haven't done full production on it yet. Hopefully, we'll be in production by July or August this year. That said, so far from what we can see, it's going to free up some time for certain staff that has been running these tasks manually overnight. Now, if someone gets notified of an issue, then they can address the issue. In the long run, it'll free up some time and resources to focus on other tasks. 

I like the interface, including how I can see everything and how I can put the jobs together. Depending on the experience, I can either use the GUI or I can use the command line to create jobs based on JSON scripts. It provides that flexibility for someone who has no experience of using Control-M as well as with someone who's a full-blown developer that can get very complex with creating these jobs. Generally, it provides a good interface for everyone with different levels of experience.

Control-M doesn't really process data as far as I can tell. It orchestrates other scripts. From what I understand, Control-M doesn't really ingest or analyze any data. It's a tool to help with the processing of data on different platforms. I can tell it to run a script on one server, to send the data over to another SQL server, or a different platform, Power BI for example, and run a script on Power BI so that it can ingest the data when it gets there and do what it needs to do. Once that's finished, I can send it to another platform to put a dashboard together based on when that data is available.

Once one understands the process of how it functions, it's pretty simple and straightforward to create, integrate, and automate the pipelines. There is a learning curve to understand how it all works, all the components, and all the requirements for parameters and different options. However, it's pretty simple once someone has a basic understanding of how it all works.

The Control-M interface is good for creating, monitoring, and ensuring the delivery of files as part of our data pipeline. There's a wealth of information in both the full client, as well as the web interface that they have. Both are very easy to use and provide all the necessary material to understand how to do various tasks. The help feature is very useful and informative and everything is very easy to understand.

It’s great that Control-M orchestrates all our workflows, including file transfers, applications, data sources, data pipelines, and infrastructure with plugins. There are a lot of plugins and we haven't used all of them yet. Primarily, we've only used the file transfer plugin, the Azure file service, and Azure functions. Primarily, the developers have used that to put the various tasks and workloads in place. While we haven't fully utilized everything in Control-M yet, we're learning how to use the various functionalities and transitioning from our legacy scripts and data sources. 

Some of the documentation could use some improvement, however, it gets you from point A to point B pretty quickly to get the solution in place.

I've been using the solution for almost a year. 

It seems stable. I haven't rolled the solution out to a very large environment yet. The solution we're working on right now seems to be working fine. All the issues we've seen have to do with us figuring out connectivity between Control-M and the cloud services, however, I haven't had any experiences with issues around stability with Control-M.

Right now, it's a small deployment and we have it in four environments. We have it in our dev, QA, UAT, and production environments. Right now, there are two application teams that are using Control-M, however, we have another two or three teams that are looking to get onboarded.

It's pretty scalable. I haven't done a deep dive look into it the scalability, and we haven't identified a need yet to scale out. It seems pretty scalable, yet I'm not sure as I can't speak from personal experience. I don't have experience with it yet.

It was a challenge to get the direction on how Control-M should be implemented. As we learned about new requirements from the customer, implementing those with help from the engineers at BMC was hard. The third-party contractors were one issue, however, when I escalated it to our customer representative, he was able to get me in touch with a dedicated BMC engineer and she was able to give me the information I needed and provided the context and direction on the best approaches. I wasn't able to use the third-party engineer that was assigned to us, however, the internal resource was a great partnership to help move this along.

Neutral

We were using Microsoft and internal tools. We used the basic Windows tools that were built in.

We went with this product to centralize the deployment and to centralize the management of all of the workloads.

Some of the installation components were really complex. I'm more on the infrastructure-based side of Control-M, I deploy it and then get it ready for functional use so that the application developers, script developers, and workload developers could easily access it. It took me three weeks to figure out the requirements for getting the SSL certificates as the documentation wasn't really clear on what those requirements were. Once we figured it out, it was simple, however, the support staff couldn't give me the right information to understand what was required.

It seemed like there was a gap in expectations on what was required for certificates. In terms of the installation overall, it wasn't clear what each variable or what each configuration point was referring to until we were well versed with how everything functioned. Then we were able to say, "Oh, this is what that field meant and this is what was required here." However, during the installation process, there was very limited information on what was being asked at each configuration point.

In terms of strategy, there was a challenge with the customer. I was the third or fourth resource that was brought onto the project. The first three people that handled it, internally and externally, had trouble figuring out what the expectations were. I was handed the baton at the last moment. I had to tie up loose ends and try to get this up and running for the CIO before he started to send up red flags to BMC.

We had an integrator, however, setting up the timing with the integrator was a challenge. What I got from my company and the general expectations weren't clear. When I did get clarification, I wasn't able to get ahold of the contractor since he required a week or two weeks lead time. We then ran behind based on the lack of information I got. Setting up time and requirements was a challenge.

I'm also a contractor working for a customer. Being a third party, trying to work with another third party with minimal information from the client, was just a challenge all around.

There was another team handling the pricing. I'm not sure of the exact costs. 

Our customer chose this solution. 

We do not use the Control-M Python client and cloud data service integrations with AWS and GCP and we do not use Control-M to deliver analytics for complex data pipelines yet.

We haven't gone into production yet, so we haven't rolled this out to all our customers. We're still testing the features and we'll be starting the UAT in two to three weeks.

Right now, we're still in the early stages of rolling everything out. We've gone through the testing in our development environment and in QA to make sure things are good. Now, we're testing performance in UAT internally, and then we'll have customer validation within a few weeks before we go into production.

The solution will play a very critical role in day-to-day operations. However, it'll be at least two months before it becomes critical. Right now, it's still being implemented and evaluated.

It is pretty flexible on various cloud solutions, working with different cloud technologies and platforms. I would say potential users should take a look at it. It does provide a lot of flexibility, especially with the application and integration component that they have. The developers seem to really be able to get what they need out of the AI or the application into an integrated product or feature set.

Before installing Control-M, have a sit down with the Control-M solutions engineer and make sure you share with them all of the details of what you'd like to accomplish before deploying the solution. My client just said, "We want this" and they didn't give us the details about what they were looking for. We ended up having to redesign a few features, as those items were not clarified as part of the installation. When I was brought on board, the customer didn't mention they wanted HA, so that came later. At that point, we had to reinstall and add more servers.

The person who signed the contract was focused on MFTE, which is the enterprise file transfer tool or managed file transfer tool. However, later, the architecture team decided not to use that and go with another tool. Due to that decision, the client could have gone with a SaaS solution instead of the on-premises solution to Control-M and saved a lot of time, money, and hassle on deploying the on-premises infrastructure. So my advice to others is to make sure that the needs and the functional usage of the tool are identified clearly before purchasing or implementing the tool.

I'd rate this tool ten out of ten. It does what it says it does. 

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.

Control-M is the primary tool used in our department as an interface between desk jobs and SAP. I create and monitor the jobs in Control-M and that ties into SAP.

At this point, we are using it as a batch scheduler, which is primarily used for SAP. We use it for everything financial, like payroll, because SAP is our primary ERP.

Our system administrator uses Control-M when he is scheduling batch jobs. 

Our SAP jobs are fairly critical, because there are a lot of collections from a financial aspect coming through on a daily basis. From that regard, Control-M is fairly critical for us. We need to know when and if jobs fail since that has an impact on the collection of money.

We used to have multiple shifts of people sitting there and monitoring our jobs until the introduction of Control-M. So, with Control-M, we have been able to reduce the human capital, in regards to shift workers. Therefore, we are saving money from a cost perspective, in this regard, by about 25%. We have had a 50% reduction in staff. The ability to monitor and be notified, when our jobs have on time completion or fail, has had a big impact on the company.

It is more about the notification tools and its ability interface with SAP. It has the ability to notify people about jobs and schedule based on prerequisites, because this is not something that we can actually do within SAP. For example, if one job is dependent on another job completing, SAP doesn't have this capability. This is why we went with Control-M. 

It is very simple to use. I have only been in this position for four years, but it was really easy for me to pick up and monitor Control-M.

In the client, it provides a unified view for me. I can alter the view that I want to see jobs and conditions. This is nice to have. The fact that you can see everything in one space is very important, especially these days where everything is about data and monitoring as well as because we are working from home on a global basis. So, in real-time, I can monitor jobs, failures, or anything that might be stuck. The real-time monitoring and the ability to see everything in one place is important for us because we operate 24/7.

I use the mobile and web interface. I started off with the desktop client, and there are some slight differences in the interface between the mobile, web interface, and desktop client. This is a nice feature, because when I am on the road or going for a walk, then I have my mobile with me and I can get notifications if I need to run anything. Then, I can just log on from there.

All the modules within Control-M can interface with SAP.

Everybody's biggest gripe is the reporting capability option. It is a gripe because there is a lot of information in Control-M, but the solution doesn't have a good reporting tool to extract that information. Now, if you want all that information, you need to rely on another third-party BI tool to extract the information out of Control-M.

Two or three years ago, I was at a seminar where they said that they were looking at improving the reporting. However, from that time until now, there hasn't been much of a change in the reporting capabilities. Especially in today's day and age, where accessing data has become very important, this is something that they should be looking at.

We are using Commvault as our backup application. Currently, there is no integration between Control-M and Commvault. 

I have been in my position as an operator for four years. The company has had Control-M for over 20 years. 

Over the last three upgrades, Control-M has improved quite a bit. When I joined our department, Control-M didn't have a good reputation because it was always falling over. All our issues were addressed by Control-M with their upgrades. 

In the latest version, we find it has been extremely stable. We haven't had many failures as far as the program is concerned.

Generally, we don't interact directly with BMC because we have a service provider that we use, Blue Turtle. So, we interact with Control-M via Blue Turtle for any queries that we are having.

The initial setup was done before I joined the company.

We have a system administrator who applies our Control-M updates.

Control-M has helped us improve Service Level Operations performance. It helped us from the monitoring perspective. Now, we are able to control real-time monitoring and real-time notification of any failures that would occur within the system. Because we run it 24/7, we have notifications for any failures that have been setup. They will come through on our mobiles, and in that regard, Control-M has helped us.

Unfortunately, I can't compare it to anything else.

It just works. Control-M is very good. You only need to look at something else when an application gives you problems. However, in our environment, it is stable and just works. We haven't even bothered looking at anything else.

I can highly recommend it. It is very easy to learn. It is very stable. It has multiple interfaces, e.g., you can use it on your desktop, access it via the web interface, or access it on a mobile. The support that you get is actually quite good. It is a tool that I highly recommend. For what we require it to do, it does exactly that and more.

We have a system administrator, a chief scheduler, who is my supervisor, and two operators, including me. The four of us are power users who have scheduling capabilities in Control-M. We have different people on our BI team. Overall, 10 people have various levels of access.

We have tried Control-M as part of your DevOps automation toolchains. We are only getting into DevOps now as a company. We are still playing around with it. Currently, we are still fairly separate as far as DevOps is concerned. My department is basically the middleman between dev and operations. Whatever dev wants, we will create those jobs and test them. Once they want to send them into production, they let us know, and it then goes to operations. We are the center for those types of things.

Because we went into lockdown and the financial impact of the lockdown, projects were placed on hold. This year, they were& still on hold. Probably sometime next year, we will be starting on those projects again.

I would rate Control-M as eight out of 10 because the reporting needs improvement.

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 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.

In my organization, Control-M supports large services and data management. We are mostly using it to schedule jobs in applications, like Informatica PowerCenter, PeopleSoft, and SAP.

We are using the desktop interface.

We utilize Control-M’s streamlining of our data and analytics projects. We are in the retail industry. We are also into other industries, like gas stations, baby stores, and online stores. When it comes to data, we have a lot coming daily. It can be product, purchase, or business information. Only 70% of the data is being used with Control-M. It can be a data transfer from one location to another location. Or, it can be putting the data into a database, then storing it for the future. Every day, the purchase history and product details are uploaded to the database using a Control-M job. Because of that, our business is able to identify our customer's needs. Using its analytics, we are tracking reports that help us provide more services to our customers. Control-M is definitely playing a vital role, in terms of handling a lot of data.

There are very critical processes that we have automated in Control-M, e.g., order confirmation. This is a service when a customer tries to purchase something from our online stores. Normally, when a customer places an order, it makes updates in the background, puts some things in a database, and performs some actions, then it gives an order confirmation. That has to be done within a short span of seconds. For us, that is a critical service because a customer should receive an order confirmation as soon as they make a purchase. This is one thing that we have automated. Because a lot of things are done in the background when a customer tries to order something, the process is automated. Automation of these processes improved the quality of our service. It has also reduced manual efforts and the time to deliver services has decreased, giving us a time advantage.

The scheduling feature and scheduling tool are the most valuable features. I like the scheduling services that we have in Control-M, which are very beneficial to our organization because they are automating things. There is also less manual work. We can schedule a task without any manual interruptions.

We use the File Transfer feature from BMC. Before File Transfer, we used to have to develop the script, which was always a problem for us. After using File Transfer from BMC, a lot of our issues were resolved. Also, it is ready to use. There are many extra, additional features, which help our day-to-day work requirements. File Transfer is a fantastic feature of BMC.

The web version is quite new. When compared to the client version, the web version has made a lot of improvements that needed to be done.

Because of the Role-Based Administration feature, we have been able to give autonomy to our users to develop their cycles how they want. Using this Role-Based Administration feature, we are able to give restricted access based on their job roles. 

The user interface is not that good. While we know that BMC is working on it, the user interface is how we work in the client. Also, the web version is quite slow when compared to the client version. 

Currently, per our requirements, we are planning to use Control-M Web more. However, because the UI is not good and still not up to the standard, we are not using it fully. This is one area where BMC needs to really focus further development.

For installing or upgrading the PeopleSoft and SAP plugins, currently there is no way to do it via Control-M Configuration Manager. So, we are installing or upgrading the plugins, like PeopleSoft and SAP, manually. If BMC could provide an option via Control-M Configuration Manager to upgrade these plugins, it probably would reduce a lot of manual work as well as ease our work. This is one improvement that I personally want to see, because it would help our way of working.

I have been using Control-M for four years and 10 months. It has been close to five years.

Control-M is 100% stable.

For day-to-day administration of Control-M, normally less than five people are required in our organization.

As per our requirements, it is okay most of the time. We do not need to search for another solution. It is very scalable.

There are currently 700-plus people using Control-M services. Their job roles are software developers and system engineers. 

In 80% to 90% of situations, BMC has provided better solutions. In rare cases, the support was not an asset.

BMC Control-M videos and webinars are being uploaded on YouTube or the BMC website. These are really helping us a lot to solve issues or understanding some things. One thing that BMC needs to continue is giving more webinars and uploading videos.

My company used a couple of applications before using Control-M.

When we migrated Control-M, we tried to use Control-M's Conversation Tool. However, it did not fully satisfy us per our requirements.

Normally, we do upgrades ourselves. However, if we need assistance, then we normally contact BMC by opening a case in Case Management.

Control-M has improved quality levels as well as standards. When it comes to cost and time, we have seen an improvement of approximately 70%.

The use of Role-Based Administration has eliminated the need to submit tickets or requests to the Control-M administrator.

BMC's price is based on the number of jobs.

If it is for scheduling, we only use Control-M in our organization. For non-scheduling solutions, then we probably will look at other solutions that are feasible for us.

DevOps automation toolchains are in our roadmap for next year.

We want to use Centralized Connection Profiles in the future.

I would rate it as nine out of 10.

Most of my customer's jobs now run on Control-M, mainly on the finance side and for data management. Those are the core applications that we are running. We are using it as a scheduling tool. 

We have a few other applications that we are migrating to Control-M. Until about two weeks ago we were running on an older version of Control-M, so not many people were interested in migrating to it. But now we are running on an updated, supported version. So more applications should move to it.

Control-M is deployed on-prem.

Let's say the business wants to run some reports. We give them a console or the Self Service where they can run jobs. That way, they don't have to depend on the IT team: “Hey, can you run this job?" And then they have to open a ticket and the IT personnel have to keep to the SLAs. Instead of that, we give them Self Service where they can run their own jobs and they can see the data instantly.

For each job we have SLAs and, based on the SLA we define which ones are critical. The most important processes for us include the SFTP process. We have a few files that are very important and are generated every day. They have to be delivered to the business before they come into the office. That is a very critical process. We tried various options but after implementing Control-M we had better results. Another of our critical jobs is what we call our master data management, where we have near real-time data. We have a few SLAs where a job has to be completed within 20 or 30 seconds. That means the data has to be delivered within that amount of time. Using Control-M helps us to monitor and deliver critical data to the business.

We used to use a native scheduler, like a cron or MDM scheduler. Those kinds of schedulers were very effective, but there were no cross-platform capabilities. With Control-M, we have both types on a single page, and we can see when a file is available and when it's picked up. If I have two different data centers and Job A is running data center 1 and Job B is running in data center 2, when we used the native schedulers for moving files and getting alerts, there was always a delay of a couple of seconds. We have tight SLAs. With Control-M, we're able to deliver on time. While our earlier and our current schedulers are automated, we have a better solution now.

Control-M has also helped to improve our Service Level Operations performance. If I had to take a wild guess, I would say it has improved SLO performance by 20 percent.

The main reason we came to Control-M was to integrate everything together and have it all in a single platform. We use different applications, and integrating them was not possible previously. With Control-M it is. Apart from integration, the main features are for long-running jobs and SLA alerts. But there is definitely a lot to explore and to work on within Control-M.

The solution provides us with a unified view where we can easily define, orchestrate, and monitor all application workflows and data pipelines. We have a team called pro-mon and they monitor all the jobs for us. A single view makes it easy for them to monitor things. Control-M comes with a documentation section for each job. As an SME, I put in the high-level steps in the job documentation; what to do if a job fails. They can read it and do level-one support. Some jobs are very critical and require an immediate call, but with other jobs they can wait, re-run, or read the documentation to give them some guidance. That really helps all our teams. That single view for the monitoring team, where they can see things in a single application, is important because the business needs all jobs completed within their SLAs. Indirectly, it's helping the business to get its data on time.

Another reason we use Control-M is to integrate file transfers within our application workflows. We have cross-business functionalities, where one business generates something and another business wants to use those files. We use a lot of MFT and AFT functionalities. As a result, Control-M has definitely improved our timelines and SLAs. We have an easy-to-monitor solution now. Before Control-M, each application team had to monitor its own jobs. Sometimes they would miss something and they wouldn't know that there is a mistake in a job. But once Control-M came into the picture and we had a dedicated team to monitor everything, we were able to provide timely files to the business. The business is very appreciative of the improvements after implementing Control-M. It has improved things a lot when it comes to providing files to the business on time.

With my current customer we have been using Control-M since 2017. I started using it over the last four or five years.

Now that we are using the supported version, we can leverage a lot of the features. Going forward, it's going to be very actively used by all our business teams, including all the applications teams. We don't have many jobs at the moment, around 200 or 300 jobs, but down the line, in the next six months or year, we are going to double that count.

It's a good tool, and they're coming up with a lot of new features and a lot of improvements on the scalability side. Version 20 might have come up with more features and more performance-related things.

Control-M is running multiple applications for us, including SFTP, MFT, Arkin, Informatica, and Java. There are also a lot of BA jobs and a few OS jobs. We have also integrated some of our reports with Control-M and I'm running them on my local machines. We are planning on expanding Control-M to other applications in the future. That's one of our next steps, to go to applications at the organization level. We are working on it.

We are not heavily dependent on Control-M as of now, but we are slowly migrating to it. Our users of Control-M are developers and application owners, which puts our number of users in the double digits. There are some business users as well. But it's more the application side and the team leads who are using it. Previously, I worked with a very big financial company where we had thousands of jobs. Everyone was using it there.

Jesse, my account manager, is very prompt and he answers all my questions in a timely manner.

We have hardly reached out to the support team. Whenever we would reach out to them when we were running on the older version, they would always say, “Hey, you have to upgrade in order to troubleshoot.” In my experience, the support has not been excellent but it has met expectations. Since upgrading our version, we haven't reached out to the support team.

With earlier versions, the support was not accurate or delivered in a timely manner. What would happen is that I would be in production mode and I would have an issue and would want to get someone on a call to see what was happening. But they would always say, “Hey, provide the log first and then we'll review and we'll get back to you." I feel that when a customer asks about a production issue, they should jump onto the call to see what is going on, and then collect the logs. At least that would give me hope that the support is there and that they are on top of it. I did not get that kind of support from Control-M.

It could be this was just my experience from a very limited number of tickets. Once or twice we had a production issue and I was expecting that someone would join the call immediately. I know they need a log to see what is going on, but before that they could jump on and see if they can fix it. Sometimes an expert will know what the problem is before seeing the log.

I do work with support from other vendors' applications as well, and I get a different response from those vendors, so this is something BMC might have to improve.

We moved from native schedulers to Control-M.

We have in-house people who are expert enough to implement Control-M, but due to other engagements, they were not able to do so.

The initial setup was straightforward. The vendor implemented it for us. We reached out to our account manager from BMC, and BMC sent a certified vendor, Cetan Corp., to our environment and they implemented it for us. Overall, it was a simple installation, a simple environment. Our initial deployment took about three months, end-to-end.

We recently upgraded and we also used a partner for that, VPMA Global Services. The process took about six months but that was not six months of work every day. The actual working time on it was about one month. The other five months were due to securing hardware, testing things, et cetera.

When we went with VPMA for the upgrade, we gave them our requirements, how we wanted our implementation to be. They came up with an architecture diagram and we had an internal discussion about it. The VPMA team came up with their recommendations, multiple approaches, and we choose the best of them.

Both partners were recommended by our account manager at BMC.

I also definitely check the integrated guides and how-to videos. They are very helpful. Products like this might be using different approaches, but they have the same types of features, so we had an idea of how to implement this. We know there are best practices so we went ahead and searched the integrated guides and YouTube support. We got a lot out of them. They're very helpful for our new people. They can search and go through the how-to videos.

We don't require many people for day-to-day administration of Control-M. We spend around one to two hours on Control-M most days. The monitoring team is always monitoring all the jobs on the screen. But the application owners, who are the admins, hardly spend two to three hours on it per day, unless there is an alert.

Whatever we have spent has definitely been worth it. At every renewal we evaluate it internally. As a Control-M SME, I have to provide some stats in terms of man-hours, the amount that we spent on it, the stability, and SLAs. Based on these, we have always had a good impression. We have to justify it that it's worth the cost, and it is.

Initially, our licensing model was based on the number of jobs per day. That caused some issues because we were restricted to a number. So at our renewal time we said, “We want to convert from number of jobs to number of endpoints.” That cost us extra money but it gave us additional capabilities, without worrying about the number of jobs.

At first we had the standard edition and later on needed some additional features and we paid extra for those.

Control-M helps us to proactively monitor things and see what is coming up and what is happening. Based on that, we can take steps for resolution. But I don't think Control-M itself has the ability to proactively fix issues.

Overall, it's a good automation tool. And it gives us a single view of the customer. I would advise going with something like it. I'm not going to advise about any particular solution. All these tools are very powerful and give you a single view.

Because of security issues that we have, we are a private and public enterprise. Our main area is the lottery in Portugal. This is the most important business that we have. Also, because the money comes from the game, we need to invest it in social, health, and real estate areas.

For my current organization, it is a new tool. We are implementing the tool right now. We have a lot of impact jobs running every day and night, but in a skeletal matter. So, these jobs are running at one o'clock in the morning. With historical run jobs that we needed, we know it took six or seven hours to finish. Then, we have another cron job in another system at eight o'clock. With Control-M, we can reduce a lot of this time. Because when this job is finished, it will immediately start the job in another system. At this moment, we do this manually with an operator. Sometimes, they have errors because it is manual. It is not robots who do the job. Also, it takes a long time. We are losing time between jobs, if it is not automatic.

Our operator guys mostly use the web interface. As a client, we are more using the UI for the planning of the jobs. However, if we want only to do monitoring, then we only use the web interface. As we continue to work from home, there are a small number of operators who are still at our work. For security purposes, it is important to have the web interface in place because we don't like to install it on our clients because we don't have administration of the PCs. We cannot install on laptops without authorization. Access to Control-M only with a browser is really important and makes our job easier to do. We can access Control-M with a laptop, app, or mobile.

Before Control-M, we didn't have a centralized view and could not view what happened in the past to determine what will happen in the future. The Gantt view that we have in Control-M is like a project view. It is nice because we sometimes have some application maintenance that we need to do. So, in a single console, we can hold the jobs for the next hour or two. We can release that job when it is finished. This is a really nice feature that we didn't have before. It is something really simple, but we didn't previously have a console where we could say, "For the next two hours, what are the jobs that we will run? And, hold these jobs not to run." This is really important.

We use the Conversion Tool for audit purposes. We have had things working for a long time, but not documented. The Conversion Tool is nice because it helps us understand our jobs, whether they should be in Control-M or not. 

The most valuable feature for us is Managed File Transfer. We have a lot of file transfers in-house. Every FTP was being done by hand. Managed File Transfer is simply the best thing for us. This is the most used feature.

The credentials vault is really important. Before Control-M, every user's operator needed to know the username and password to access a system. With Control-M, we don't need to share passwords anymore. We write down the username and password one time, then we use it without knowing the password. 

The amount of integration that Control-M already has. We use the web services. We are using the SQL and Oracle integrations because we have a huge environment and a lot of applications in-house. Because we have integrations with all these tools, we don't need to give access to the operators. Now, we have everything in a single pane of glass. The operators can see all night what is happening, where, and if they need manual intervention.

One of our most used features is Control-M's library of plugins for orchestrating and monitoring work flows and data. We have a lot of different applications, plugins, and API automation, which are really important for us. We are migrating a tool from Apache, which is Java code. So, we can schedule the Java code with the API automation plugin that Control-M delivers for us. We are now starting to operate this way.

We use the Control-M Role-Based Administration feature. It is integrated with our Active Directory. We have groups in Active Directory, who are administrators and operators. Then, we map this role-base directly in Control-M. Role-Based Administration empowers us to decentralize product teams to manage their own application workflow orchestration environments with full autonomy. We divided this by environment: production, non-production, and demo environments. For each of these environments, we have different roles in Microsoft Active Directory. These roles are implemented by Control-M Role-Based Administration.

The use of Role-Based Administration eliminates the need to submit tickets or requests to the Control-M administrator. They don't open tickets and are autonomous when doing their job. From a security posture standpoint, it is important for us because we know that only the people who have credentials can access these environments, doing the job that they have to do.

We use Control-M Centralized Connection Profiles. We create the connections for the user and password. After that, we don't need to share passwords anymore, which is important for us.

We develop software. More frequently, we are working with microservices and APIs, using our integration tool, MuleSoft. While Control-M is really a good tool to integrate with other tools, it is important for them to continue improving their microservices and API.

I have been working with Control-M for more than 10 years. First, I was working in a consulting company, as a consultant, where we implemented Control-M. Now, in the last year, I have been a customer in a huge organization in Portugal. 

We can work with jobs that should run daily because of it. When we need to do an upgrade, it is really important for us not to have any downtime.

We are always afraid to install the latest version. However, with Control-M, it is really comfortable to move onto the latest version because of the stability. When I worked as a consultant, I never had any problems. Even when we had Control-M in two data centers, if one goes down, then we can run Control-M in another data center. Few software solutions have the stability of Control-M. 

We have different areas: real estate, games, social activities, and healthcare. The scalability for us is really important because we have different agents installed by business area. We don't mix it. Also, we have to always buy our VM servers per business area, so we can upscale how we want, which is really nice to have in Control-M. Critical jobs can run from different servers if something is not working.

BMC support is an eight out of 10. Everyone has centralized outsourcing for the first line of their service desk. They always ask some of their normal questions. After a while, once those guys know our workflow and understand that we already have some knowledge in Control-M, it is really fast to solve the problem.

We really needed a job scheduling tool. At the end of the day, we bought BMC Control-M. It is for a distributed environment where we have a lot of different working systems, operating systems, and applications. Control-M is the application and tool that meets our expectations.

The initial setup was straightforward. It is really easy to understand the architecture, and even install it. Based on some internal rules that we have in-house, Control-M fits well with our architecture.

It took a day to install and a week to implement. After one week, we had some jobs working and were able to get the users to see, control, and monitor the jobs. We had it deployed and working in less than a week for Windows, Linux, and HP-UX operating systems as well as VMS.

My principal difficulty implementing in-house was that people didn't understand what the job scheduling tool can do for us. It was long hours, and a lot of days, saying to our internal colleagues that this is the right tool. With this tool, we didn't need to have a lot of consoles anymore, i.e., working 24/7 to try and open every console to understand what is happening. We can have a single tool for all the jobs, applications, and operating systems. We can monitor and schedule all the jobs. They thought this is rocket science and doesn't exist. This solution has existed for a long time and is really important. 

The use of Centralized Connection Profiles has helped lower our total cost of ownership. Before BMC Control-M, we had different environments with the same users. We saw before that even the passwords for the different environments are the same. Before Control-M, we had passwords in emails and chats. Sometimes, the password would expire. With Control-M, we changed that. Every environment has an administrator who needs to write a password. We give them access to write the password directly into Control-M. The person configuring the job only needs to know who the user is, not the password.  With this functionality, the time that it takes has been reduced.

It reduces the duration for a lot of our jobs. We no longer have a window for maintenance applications at night.

This is an area where it is a little difficult to work with BMC. They want to do licenses by job, which is what we have. For example, the simplest is to license by job, but they can also license by nodes. While the licensing is simple to use, it might not be the correct licensing model for the customer. It is okay because we want to license by job, which is something measurable. At the end of the day, licensing by job is the most important.

We evaluated other vendors, like CA, but CA was bought by another company, and we have been a little afraid. Our organization always buys with a tender. Our tender had a lot of requirements on it and only Control-M could meet them all. It was a public tender, so we didn't really choose Control-M. We had a huge list of requirements that we really needed for job scaling. Only BMC could do it. IBM Tivoli tried to answer, but it didn't meet all our requirements.

Most tools have a huge GUI. You need to open five to seven windows to go to the parameters. Sometimes you don't have all the parameters in the GUI. With Control-M, it is three clicks and we have all the information that we need. We can see that in Control-M, we can see that all the perimeters are there for one job, like Managed File Transfer. It is very intuitive, and we can understand where to find the parameters to configure.

I think that every single company should have Control-M installed, because it is really important and useful for everyone.

I would rate this solution as a 10 out of 10.