JAMS Reviews

We have it deployed in our cloud Azure VM environment. So, we have it physically installed on our servers, but it is a cloud deployment.

There are a number of different checks that it does. The first thing that it will do is try to connect to the agents. For example, if an agent machine isn't there and isn't available, the way we have everything set up is that the first job will fail. However, if you have a series of jobs with dependency, succession, then you can set it up so it will prevent the other jobs from running. This way, it is not running things out of order or running things without a job where all the other jobs are dependent upon the first job running successfully. There are a number of different ways that you can set that up within JAMS. We definitely use some of the more simplistic ones since that is what works. 

We don't need enormously complex workflows in the system, and the main functionality within JAMS is really what works for us. We have found that trying to keep it simple, not making things overly complex, within our job scheduling and configuration has worked best for us. If it isn't broken, don't fix it.

It makes everything that we want to do so much easier. We have had a number of instances in the past where we have had developers who have been working on a project, and even though we have had JAMS for all these years, they will create some SQL Server Agent job, or something like that, to run a task. When it is in code review and development is complete, the question always comes around, "Can JAMS do this?" The answer has always been, "Yes." Pretty much anything we have ever developed could be run by JAMS. 

Our operations team who manages JAMS picks the project up, puts the jobs in, and starts running them. Whether it is the developer or some other resources somewhere else in the company, they want to be kept in the loop on the processing of those jobs. We can use the built-in JAMS alerting to keep them up to date. They can be alerted only when there is an error. Or, they can get an alert anytime the job runs so they know whether it was successful or failed. Over the years, there has been a greater adoption of people coming to us, saying, "Hey, can I run this in JAMS?" Instead of them going off and creating it on their own.

Its Interactive Agents are critically important for running jobs on all our various servers. If we didn't have that, we would have to do something individually on each of those different servers, trying to time everything out. It would be nearly impossible.

The most valuable feature is the basic core of the software itself. That is just the level at which you can set scheduling and dependencies between jobs, how everything can be set and scheduled based off of one another, and the ability to run jobs across 25 to 30 different virtual machines. It gives the ability to be able to run jobs on all those servers as well as have them all be visible. In the schedule from one centralized JAMS client location, we can bring up the client interface and see everything that runs across our entire infrastructure, which is really invaluable. We can instantly access all the log files for anything that happens, e.g., if we get any job errors. That is definitely what is most valuable to us. 

There are some different batch queue features, e.g., we can quickly change the servers where jobs are running. When we made a full move to Azure to be fully cloud based, we had to change all our jobs and the servers that they were going to be running on. The way it had been originally set up was that we used batch queues, where each job would run on a particular server and it would be assigned to the queue, which had the agent definition in it. That told it what server to run on, which was very easy. We didn't have to go through and change thousands of jobs. We only had to go through and change about 20 to 25 different queues, then just point them at different servers. Therefore, it was a very quick and easy change. 

We have used some of the built-in PowerShell FTP capabilities within JAMS as well as some of the other PowerShell capabilities. We also use the triggers a little bit, when we are watching for files to appear in a particular directory, etc.

The exception alerting process is reliable; it works. We don't do anything really fancy with it, and it is mostly based on the actual jobs themselves. For example, if an SQL job, some Windows executable, or an SSIS package that we're running returns an error exit code, JAMS certainly handles that and lets us know. It then does, with the rest of the job surrounding it, what we have configured it to do. From that perspective, it is great. 

We have some specific instances where if jobs run too quickly or take too long to run, we use the exception alerting process on probably a few dozen different jobs that we have that are really important. The few times that it happened. It has saved us a lot of headaches because it is able to report those exceptions to us. 

We use a fairly decent amount of the log file exceptions, where you can go in and parse the JAMS job log file for specific entries as it goes through. Then, it can actually error the job out for a job that otherwise might not end in an error. In our case, we wanted to be alerted and have it halt a process if some specific text string shows up in the job log. We have that set up on a number of different jobs, which saves us from a lot of headaches.

It has worked out pretty well for helping us handle complex scheduling requirements. We use it in one specific instance where our customers interact with our web-based platform. It has a section where our customers can go in and run one-off versions of their specific processes. So, they will go in and upload a new file, then they want to basically process that file into the system. What they can do is go to the page, upload their file, and then there is a button there that allows them to process it. That button actually links directly into our JAMS server using the JAMS APIs. That will kick off the jobs within JAMS directly. We have it set up so it only allows it to run it during certain times a day. It can check and monitor to see if an instance of a job is already running for that client. If it is, it returns back and tells them that they need to wait for the current one to finish. It returns the actual history from JAMS so they can see all the previous instances of their jobs that have run. This is a really nice feature that our customers really appreciate. It also saves us a lot of time. What would happen in the first couple years before we implemented this, our customers would upload their file, but then they would send in a support ticket for us to run their processes during the day and all our customer processing happens mostly overnight. Therefore, they would want this intraday update of the process. As soon as we implemented this for all of our clients, those support tickets just disappeared. It made a big difference in our ability to support customers.

I would like the ability to have the JAMS client, where we monitor everything, be fully web-based and secured so only certain people can access it. It should be set up and look similar to the actual JAMS client that we use as a desktop application on the server. A fully web-based JAMS would be nice for traveling or when you are not able to directly access the actual server with the client when we want to log in.

All my machines at work are Macs. JAMS client is a Windows-based thing. It is all built on .NET, which makes perfect sense. However, that means in order for me to access it, I need to connect to a VPN, then log onto one of our Azure VMs in order to access the JAMS client. This is fine, but if for some reason I am unable to do so, it would be nice to be able to have a web-based JAMS client that has all the exact same functionality in it. There are probably a whole bunch of disadvantages that you would get with that as well, but that is definitely something that would make life easier in a few cases. 

We have been a JAMS user since late 2013.

It has been incredibly stable over the last nine years. 

The only issues were few and far between. They baked more down to Windows than JAMS, but that is just how JAMS interacts with Windows, and you will get an instance where a JAMS agent will stop responding. I have probably had that 10 to 15 times total over a nine-year period. It is really more about the Windows VM needing to be restarted. It was something in the Windows network that was out of sync, so it wasn't JAMS causing the issue.

We had no downtime at all for the complete movement of an entire environment, which was great.

The scalability is fantastic. We have never had any issues. We went from a couple hundred jobs to running 6,000 to 7,000 jobs per day now without issues whatsoever. It is extremely easy to use. I feel like if we had the manpower to put all the jobs in and stay on top of them, we could run 60,000 jobs a day through it without any issue. The scalability is more about the server environment that you are putting JAMS on rather than JAMS itself.

Right now, we have two people whose main responsibilities are managing JAMS. That is for new jobs, job updates, looking at job errors, monitoring, etc. Then, we have two to three other people who work in some siloed areas, so they manage their own jobs, i.e., creating their own jobs when they go in. They are still monitored by the main team of two, but there are a few other people who manage it. Within our company, we have about 115 employees. We have about four to five people who regularly interact with JAMS, with two of those being on a daily basis.

I haven't had to use the technical support that much, which I think is a testament to the product itself. However, anytime we have had questions, such as, "Hey, can we do this with our license?" or, "What is the recommended upgrade path if we want to do it this particular way?" They have always been very quick and helpful, emailing back right away, having a phone call, or a video screen share call with us. They give us lots of options. Over the years, we have probably used it less than a dozen times, but every time has been a really good experience. I would rate them as 10 out of 10.

It didn't really replace anything.

When I first started with Powwr, everything was being run manually, being done through Windows Task Scheduler jobs, or SQL agent jobs. It quickly became apparent that this would not be scalable. It didn't really give us what we needed, as far as visibility into jobs.

I previously worked for another company who owned and developed JAMS, so I knew of it. I reached out to them, and said "Hey, we really could use the solution here." Then, we signed up, got our licenses, and were underway. At that point, we were running about a couple hundred jobs per day. Now, nine years or so later, we are running somewhere between 6,000 to 7,000 jobs per day through JAMS. That is across multiple different servers and platforms. This allows us to keep everything in a single centralized management area where we can have different jobs running based off of ones running on other servers, platforms, and types. It has been really helpful.

For the initial deployment back in 2013, when we first started, we had one main JAMS client server. At that point, we probably only had four or five other agent servers where we were running jobs. That deployment of the software took a matter of an hour or two. It was very quick and easy. Then, we spent the next month or so getting it set up to create all our jobs within it, really figuring out exactly how we wanted to run everything and trying to make it as efficient as possible. Also, we want to be able to make it so we could do the changes, e.g., if we were moving server environments or changing agent servers. We wanted to make it easy to do that.

We did take a little bit of time with planning and setup, but the actual deployment of the software was very quick. Even over the years, when we added a new server to run jobs on, it was really simple. When we do our server deployments, we make sure that the correct firewall ports and everything are open for JAMS. This is part of our standard VM deployment process. We then just use the automatic JAMS agent deployment feature. Therefore, we add an agent and it automatically deploys. About 30 seconds later, it was done.

We deploy the agents to all the remote servers that we have within our infrastructure. Therefore, once the deployment goes out, we are able to run any of our jobs. The biggest advantage that we have gained from this is being able to tie together jobs from our multiple different servers, allowing them to essentially interact with each other through the JAMS agents. For example, we have a process that has a dozen jobs in it and the first two jobs run on one server, then the next six jobs run on another server, and the last four jobs run on a third server. This makes up a larger process that completes some goals for us.

We can take the jobs that we run and write tables. The next job can pick up data from that, even though it is running on a completely separate server. They are all tied together from dependencies, so it makes sure that the right ones run in the right order, even though they are running on different servers. They don't even need to be in our environment. 

We have jobs that we can run outside of our main Azure environment and can run on ones that are halfway around the world, as our company has a US portion and a UK portion. Therefore, we can run job processes where some of the jobs run on servers in the US and some run on servers over in the UK. As far as JAMS is concerned, it is just running the jobs. However, it is a big plus for us because we can keep everything linked together.

Back in 2013, I was the only user of JAMS. We had maybe 10 people in our company at the time, as we were just starting out. Just implementing JAMS on a smaller scale saved me probably five to six hours per day of work. That was massively significant. I was able to sleep at night. Getting JAMS in place was a game changer for us back then. As we have grown from 10 employees to 115 employees over the last nine years, JAMS has grown with us in how we use it and what we use it for.

The pricing is very fair. We have seen very minimal to no price increases over the years. We are not banging down the door of support all the time either. I would imagine if we were a company that submitted a dozen support tickets a week for the last nine years, then it might be a little different because we would be eating up everybody's time. However, for what we get out of it, the pricing is extremely fair. Back when we were originally looking and brought in JAMS, we were looking at a couple of the other competitive products that were in this space, but the pricing from JAMS was far and away better than what the other competitors could offer for the same functionality.

From my perspective, we went straight for JAMS. However, from the company's perspective at that time, they wanted to look into a couple of other competitive products. So, we did do a little bit of that. 

We chose JAMS because it could be very easily integrated into our existing environment. We were completely Windows-based. We were doing a lot of .NET development. It just fit very well. Though I am unsure, it may still be the only .NET-based scheduler out there. To have this capability was really a big plus. 

Some of the other competitive products had a much steeper learning curve. We were able to take some of our employees that had never seen it before, and within a matter of minutes with some quick training, they could get in there, create new jobs, and get things running.

For a while, we had a secondary environment set up where we would run various test jobs. Or, if we were testing out software updates, like JAMS software updates, we would run that environment as well.

I would rate it as 10 out of 10. I would definitely not hesitate to recommend it and have recommended it. 

Previously, all the jobs were on different platforms, so the monitoring was not centralized. That was the main challenge about two years ago. After implementing JAMS, especially in staging and production, we have one dashboard or console that we look at every day. It's easier to monitor jobs. It's efficient. We can easily track which jobs have failed. The administrator can work in a productive and proactive way. In one dashboard, we can navigate and see which jobs are running and which jobs have failed or have been successful. We also have direct email notifications. In terms of administration and monitoring, it really helps administrators to monitor 24/7 operations, and when it comes to the business, we give them the capability to monitor the jobs. They can monitor the jobs as well when they are executed in one place. They can navigate to the domain structures from different domains, and they can monitor their own servers every day.

We started with the custom dashboard just two weeks ago. It's easier for us to monitor through the custom dashboard. We're able to customize the dashboard for the things that we want to monitor.

When it comes to automation, we have already implemented a couple of scripts. For example, we have a daily agent check, so we created a PowerShell script to monitor that. Every day, that job executes and checks which jobs agents are offline or inaccessible, and it will then send an email notification to the administrator. We can then check the server status and identify why the server is offline or inaccessible. In terms of automation, we are able to work with the developers based on their requirements. We have already implemented different jobs. We have automated some of the API jobs. We have also automated the process of restarting application services.

We have different batch-processing jobs. Some of them are weekly, and some of them are monthly. We can proactively monitor all batch-processing jobs that are recurring on a weekly or monthly basis.

JAMS saves time when troubleshooting stalled jobs. When we have an issue, we check the logs and the execution history. We also have documentation of the common issues in Confluence. We did not encounter any major issues so far. We haven't had any fatal or severity one issues. They have mostly been basic issues. Most of the time, it was an execution issue. For example, we had a monthly patching activity that affected our servers at times. During patching, the server was rebooted, and the jobs that were running at that time got terminated. We had raised our concern with the JAMS team about the synchronization. When the server is rebooted or restarted, the expectation is that JAMS and the server will synchronize. We encountered this issue in the previous versions. When we upgraded the version, we did not encounter that anymore.

Using an enterprise system like JAMS to manage our jobs gives us peace of mind. In addition, we don't require many administrators for monitoring the jobs. In our current environment, there are only three of us at the moment. I'm working during the daytime, and the other two are working during the nighttime. Three of us are enough to monitor and manage JAMS. It's a time saver because you don't need to monitor it from time to time. It automatically manages everything.

The feature or capability to import a job is most valuable. We can import an existing job from different platforms, and all the configurations get migrated as well without modifying the code, job schedule, etc.

Its integration capabilities are also valuable. There is API, and then there is integration with Snowflake and Power BI. The PowerShell integration is also very powerful.

It has been good so far. We are very satisfied with JAMS' capabilities and features. When I joined the company, we migrated all the jobs from different environments, such as from SQL and Oracle databases, Cron jobs, and Windows task scheduler, to JAMS. We onboarded different departments to JAMS. The product and the business teams are very satisfied as well with how JAMS works. They especially like the self-service capability wherein they can provision or deploy their own jobs in lower environments. Developers are able to leverage different development processing jobs. They are building their own PowerShell scripts and are integrating with other applications through APIs.

The ACL or access permission area needs to be improved. When it comes to defining and providing security permissions, it's a bit confusing if you are new to JAMS. JAMS needs to improve the features for security access or permissions.

I've been using JAMS for about two years. 

From time to time, the JAMS team will update you about the latest release. So, in terms of stability, the JAMS team will support you in maintaining your system. We haven't had any issues with stability. We are very satisfied with that because when they release a new version, we are informed ahead of time. We appreciate that kind of engagement.

Its scalability seems good. We have a lot of users using it. We have 12 to 15 internal departments using it, and we have 300 to 400 users. The roles of its users vary from department to department. The most common roles are developers, QA, business analysts, and managers. In terms of maintenance, there are three of us who are managing JAMS.

Currently, in staging, we have around 500 jobs, and in production, we have close to 1,000 jobs. We don't have any plans to increase its usage at this time. If the number of servers increases, we will plan ahead of time and increase its capacity. 

We encountered a few issues, but we didn't have any major issues so far. When we encountered an issue that wasn't familiar to us or that we couldn't resolve or troubleshoot, we created a ticket. They set up a meeting session with us. We collaborated and identified the issue and documented the issue so that if we encounter the same issue in the future, we have documentation about how to fix the issue.

I'd rate their customer service a nine out of ten. We don't have any issues. When you create a ticket, a good thing is that they respond immediately. Most of the time, I go to the JAMS portal to create and submit a ticket. There's chat support that will immediately respond to your inquiry. That's a good way to submit a ticket to JAMS support. They respond immediately via chat. They also ask you to provide the logs in case of any issues. For an in-depth investigation, they will also schedule a meeting so that they can have a working session to review the issue and resolve it as soon as possible.

Positive

We didn't use any other solution previously. As far as I know, my team was managing the jobs for each platform separately. We didn't have a central solution before. This is the first time that we have an enterprise platform like JAMS.

When I joined the company, the database engineering team had already started to deploy it. It was already set up.

Our setup is standalone at the moment. We have two environments. We have the staging environment. All of our platforms are deployed in staging, and then we have a separate box for production. There is a plan for high availability. This year, we are planning to include that option and implement it.

We have on-premises deployment, and we also have a private cloud. We have Azure, and we are also exploring AWS.

I do take care of the upgrades. The upgrade process is very simple. There is online documentation. The upgrade procedure is quite similar to other solutions.

Based on what I know, we only consulted our JAMS vendor. We did not go to a third-party consultant.

We would have got an ROI, but I'm not aware of the numbers. We are still using this product, so there must be an ROI.

It was already deployed when I joined this company.

We had two internal people who evaluated it and installed it in staging and production. They learned it on their own. When I joined the company, I didn't have any prior experience with JAMS, so they gave me training, and I learned from them. The main challenge was that while learning the platform and its functionalities, we were also doing onboarding. We were migrating different jobs to JAMS, and we encountered some issues. For example, while migrating the jobs, we had to disable them because there was another phase of the project for communicating with the product team and identifying the jobs that needed to be enabled and the jobs that weren't needed anymore. So, we encountered different challenges while importing the jobs, configuring the jobs, and assigning the access permissions, but from that experience, we learned a lot. Overall, it was a good experience.

I'd rate JAMS a 10 out of 10 for its features and capabilities. In terms of features, JAMS has almost all features. JAMS can meet the needs of most companies or organizations at the moment. We don't find any limitations.

We use JAMS to run various tasks, such as nightly claims processing jobs. It's also helpful for moving files around and interfacing between the cloud and our on-prem systems. 

The company has 50 to 100 users, including admins, developers, and on-call maintenance staff. We also have reporting staff who monitor jobs to see if they are succeeding. 

JAMS enables us to formalize simple tasks, reducing the amount of manual work. We can package all the access needed for those tasks, so a non-expert can deal with a problem without disturbing people. It automated 100 percent of the functions that can be automated. It's the only scheduler we have. 

It's hard to quantify how much labor it replaced. It's more than 10 days annually but probably less than 100. It saves staff maybe a day every four weeks. JAMS has centralized management. It is a critical way we deal with multiple systems that interface.  

We have eliminated some tools. For example, we can use JAMS as a monitoring tool and use it in place of Enterprise Manager. Regarding time saved, JAMS saved about 15 to 20 percent compared to our previous scheduler. JAMS also costs less than our last system, significantly reducing operational overhead. 

JAMS handles complex schedules well enough. That's one of the main reasons we use it. We use JAMS to populate our data warehouse every night, ensuring the updated data is available every morning. Troubleshooting failed jobs in JAMS is straightforward. You can navigate the logs quickly, and it sends you an email pointing to the source of the problem. 

JAMS is easier to use and cheaper than our previous solution. The installation is more straightforward, and JAMS has a graphical user interface, so it's more accessible. The interactive processes are helpful. We don't use them often, but it's a nice feature to have.

It sends notifications to the person on-call when a job fails, but the failures rarely have anything to do with JAMS. It allows jobs to restart several times, which often resolves exceptions. I'm satisfied with how it handles exceptions. 

JAMS lacks source control features. Our previous solution had job control language, but JAMS doesn't. When migrating between versions, JAMS doesn't migrate all the data, like job change history, etc. Also, the scheduler doesn't have a way to make jobs invisible, so you can temporarily turn a job off if you decide not to run it today.

We have used JAMS since 2014.

The current version of JAMS is stable. It's more stable than the previous version.

I rate Fortra's customer service a nine out of ten. 

Positive

Deploying JAMS is straightforward. During the initial deployment and migration from the old system, we had to request servers and plan to deploy the client. There were three stages: installation, migrating jobs from our old system, and testing. 

The migration wasn't automatic. We had to reenter most of the jobs from the previous system manually. We took the opportunity to redesign the tasks a little. It wasn't that difficult, and we had no problems replicating the functionality or anything like that. The migration took about six months.

There isn't much maintenance after deployment. We can upgrade to the latest version in two or three hours. 

JAMS is cheaper than our previous solution, and we can run it on any server. The license for our old solution was limited to two servers. JAMS reduced our expenditures by about half compared to the other solution. 

JAMS is much cheaper than our previous solution.

I rate Fortra's JAMS an eight out of ten. 

We have batch processes that run either on-demand or on a scheduled basis. JAMS is used to manage and run those jobs.

We have realized significant savings in manpower. There's no need for operators to be submitting jobs manually, as it is automated. And the ability to chain a whole bunch of sequences or steps, again, results in labor savings.

It gives us a single pane of glass that allows us to see what is going on and that centralizes the management of jobs on all our platforms. We use it both in a production and non-production environment. We're certainly getting a lot of benefits from that.

And data is ready to go when our users need it, due to the fact that it's scheduling jobs and running them as quickly as the backend systems allow.

Another advantage is that the monitor interface gives very good information, good visuals that are color-coded so that you can quickly jump to where an issue is. That helps save time when troubleshooting jobs. In terms of our IT staff's time, JAMS is probably saving us a few hours a day.

One of the things I like the most, as a SQL DBA, is the fact that we can manipulate tables in the background. Also, the fact that you can have your own views and work with the product the way it fits best is a very helpful feature.

There are alerts if things fail, and we do have that functionality in place. For critical jobs, we also have notification that the job has run successfully. And JAMS is very good at handling exceptions. You can do retries.

In the version that we are using, it does validations when you try to delete an object and if there are any dependencies in place, the deletion process will not proceed for obvious reasons. However, there is no information provided as to what it was that caused the validation to fail. Where is that dependency? Right now, it's quite a tedious process to find which object is getting in the way. Getting information with details of the failure would be very helpful.

Also, sometimes the interface is slow. It will lock up the application for no apparent reason.

I've been using Fortra's JAMS for five-plus years.

It's a stable product. We've rarely experienced bugs or glitches.

It's also a scalable solution.

We have it in extensive use. We have hundreds of jobs that run on a daily basis, both in production and non-production environments. There are no plans at this point to expand our use. There simply is no need to have more jobs running. That said, we are in the process of doing an upgrade from 6.5 to 7, but there is no increase in the number of jobs planned.

I was not at the organization when the initial setup happened. 

In terms of training, we do not have formal training for JAMS. For the operators, it is really a handoff. It is quite intuitive for them. For admins, there is obviously a lot more to the product.

We have definitely seen ROI. It's a great labor-saving tool. The hours that would be required to manually submit and monitor these jobs would be quite significant if we did not have an automation solution in place.

The way that we have it licensed is by the number of jobs. We have two installations and there probably could be a little bit more flexibility in terms of moving licenses between one and the other. However, our situation is that we have one that is a production license and another that is a non-production license, so that may be the issue.

We have five hands-on users of JAMS including two admins and three operators who monitor and release jobs on an as-needed basis. The admins are the ones involved in maintenance, not that they're necessarily needed for maintenance, but they are the ones capable of doing whatever needs to be done.

I would definitely recommend it. Note that there is a learning curve, so you should go in with a plan. But it is highly flexible and very valuable.

We started with basic tasks because we were bringing things over from Windows Task Scheduler. We didn't have a whole lot of dependencies at that point. We have gotten much more detailed in our scheduling requirements since. We use what are currently called JAMS Setups, which in the new version are called Sequence Jobs, quite a bit, especially for our enterprise data analytics team. We do some pretty complex scheduling scenarios.

We also use it for holiday calendars that impact our scheduling and for multiple regular scenarios, such as dependencies on a file or another job or another Setup. 

Overall, we use it for basic, normal enterprise-scheduling solutions.

We've been able to automate a lot of processes that were done manually before. We're not a huge company, and we're a fairly new company, so a lot of things were being done before in Task Scheduler or in a homegrown solution called Batch Nucleus. They were also in cron and in SaaS. They were all over the place. Being able to consolidate all of that into this one enterprise scheduling solution allows us to put dependencies on different jobs between different systems. It also allows us to monitor everything from one place and gives us the ability to do some exception handling. We have unlimited licensing with JAMS and we have hundreds of environments that we have agents on and do testing on. Having one location that we can monitor everything from, and handle all the exceptions from, is critical.

We've automated our critical processes, which used to be done manually through an external product and that means we don't have to worry quite so much about manual, human error.

Because we have gone from a lot of manual processes to automated processes with JAMS, we have been able to free up IT staff time. We're not spending 30 minutes doing something manually that JAMS can do in five minutes. It has freed up IT resources, but it has also sped up our processing times. For just the Technical Operations Center team that I manage, it has saved about 20 hours a week.

JAMS has also helped eliminate “data slack” across our applications. All of our enterprise data analytics is done through JAMS, so being able to access things like Teradata, Hadoop, and Snowflake cloud solutions for data integration is important. Our company is based on data. Everything we do is data-driven, so it has been very valuable having one place where we can process all of the data and do batch schedules with chunks of data. It's been a good tool for that. Having current data ready to go when our users need it is extremely critical because we are a FinTech company. We have to be able to pull data instantaneously to make decisions. Otherwise, our customer base is reduced and there are also compliance issues. We have both financial and legal obligations to our partner companies, so that data has to be up-to-date and ready to go when they request it.

I've used a lot of the other scheduling packages in the past. The most valuable feature of JAMS is the ease of being able to update parameters on-the-fly. Also, their monitoring and historical views are pretty robust.

We are also able to go into a job that is inside of a Setup and say, "Turn this one off for a while," by using the Except clause.

Another useful functionality is being able to pass parameters and variables between different jobs, and different steps in a job, or a Setup.

JAMS handles exceptions fairly well but there are some areas where it might improve a little bit. It has to do with being able to automatically handle exceptions, out-of-the-box, rather than having to code them. I'd also like to be able to do different things, based on what the actual exception is. In our current version, there's a placeholder where you should be able to do some things along those lines, but we've never actually been able to get it to work. I've seen in the 7.x versions that that has been fixed.

In terms of automation, there are some scenarios that we're still working on trying to automate and we just haven't been able to find an applicable solution through JAMS for those yet. I'm excited to see, once we get to that point, if we can do those things in the newer version.

I started using JAMS in June of 2016. I was in charge of taking all of our disparate scheduling systems and converting everything into the JAMS scheduling package. I have used it from the ground up.

Right now we're on-prem, but we are going to want to go to the cloud sometime next year.

In the five years that I have worked on JAMS, I have never had it crash.

The fat client on your machine, for the 6.5 version, is not really reliable. It can slow down and it can get hung and you have to restart it. But with JAMS itself, the only issues we've had were when we didn't get the license key updated on time. For the most part, JAMS has been a very steady, reliable tool.

Because we have unlimited licensing, it has been extremely scalable for us. We can put agents on whatever servers and environments that we need to, fairly quickly and easily. We now have that set up as an automated process. So it's extremely scalable, based on the pricing model and how many agents you're allowed.

Technical support is an area in which JAMS has come a long way. When I first started with them, they didn't have any kind of training. The way it worked was that if we had a question, we would call their support team and there might be some back-and-forth trying to figure out how to get what we needed. But they now have JAMS University where you can go to a boot camp and learn more about the product. 

And their support is pretty good and pretty responsive. They get back to you fairly quickly and they usually have a good solution to whatever your issue is. And while they have generally been responsive, there have been several times when getting an answer has taken several weeks, instead of being able to get a really quick answer. I would rate JAMS support at seven out of 10, but I wouldn't give more than an eight for the support for any product that I've worked with. That makes a seven a high mark, for me.

Neutral

We spun off from another company, and that other company used Control-M. When we went our own way, we didn't bring Control-M with us. The scheduling solutions that we were using before were Task Scheduler, a homegrown solution, and SQL Server Agent jobs, things that aren't necessarily true enterprise scheduling solutions.

In our migration to JAMS, we had to refactor some of the code, but that's because of the way that it was coded before. SQL Server Agent and Task Scheduler were pretty easy to migrate because there is actually a conversion routine where you can log in to a machine from JAMS and just say, "Go pull the job and convert it." It would automatically convert it, and we would just have to do some cleanup. That part was easy. But when it came to some of our other stuff, we pretty much had to build it from scratch.

I was the only person working on the migration back then, so it took about a year and a half to get everything over, but a lot of that was because we were having to go find things that were being scheduled on these other boxes. Some 80 percent of it was done within the first four to six months.

JAMS is close to the lower end of the pricing models for enterprise scheduling solutions. They are much cheaper than Control-M, as well as some other products that I've used.

I also don't know of another solution where you can actually get true, unlimited licensing, where you can have as many instances and as many agents as you want. That has been a godsend for us because we have environments that we spin up and take down on-demand. There are times when we have hundreds of environments going at one time. Having that lower-cost model has been really good for us, while still being able to get the functionality that we need from the tool.

Maintenance and additional features are all included in the yearly cost, and that cost is still much cheaper than what you would pay for maintenance for another product.

The one that I had used most recently, and the longest, was BMC Control-M. It is an extremely robust product that has the ability to do some things that our current version of JAMS cannot do. For example, Control-M has the ability to truly diagram out what the flow looks like, from within the tool. My understanding, after having talked to my scheduling analyst, is that that feature is coming up in a future version of JAMS, which is cool.

Control-M also has the ability to do batch impact analysis, and to put a job at the end of a job flow that says that if anything in the job flow breaks, provide an alert. JAMS has the functionality to do that in the current version, but you have to code it. If you want to say, "If this job fails, I want this other job to run to fix it, and then come back and do this other job," you have to code it. But I believe, again, in the newer versions, it's easier to do that type of flow by using Sequence Jobs. That's the biggest area where I felt JAMS really needed to improve, in automatically handling issues, and they've come a long way.

Control-M enables you to send different types of notifications based on the output, which is also a feature that's coming up in the 7.0 version of JAMS.

JAMS has taken quite a few of the recommendations that we gave them and has built them into their newer versions of JAMS. It has been an exciting journey for us to be able to have a lot of input into how the product works.

I'm really excited that we're trying to upgrade to the 7.x version, because it's so much better. But it's a huge change to go from the 6.0 version to the 7.0 version. The tool looks completely different. It works differently, with different ways to do things, so there is a big learning curve. Since our developers build their own jobs in the lower-level environments, it's going to be a big learning curve for our entire company to start using the most current version.

We've defined our complex scheduling scenarios the way that JAMS works in our current version, but in the future version that's going to be much easier. That version has the ability to create multiple schedules on the same job, instead of having multiple jobs with different schedules doing the same thing.

In terms of the upgrade process, we have multiple instances, including development, stage, and production. We've been trying to build a test environment and we have been doing a lot of our tests there. For our actual cut-over and conversion to the newest version, we are being told that we can actually upgrade in-place, instead of having to do a conversion of our database. We're going to take a two- to three-week freeze on any scheduling updates and on adding anything new. Then we'll convert our development instance and train all of our developers on how to use it and what the differences are. We'll let them test. Then we'll upgrade our stage environment and let them test on that. As soon as all of that looks good, we'll do an upgrade of our production system.

We will be working with HelpSystems on the upgrade when we get a little bit closer to it. At this point we're still trying to figure out exactly when we're going to be able to do it. But we have asked them multiple questions and gotten a lot of good feedback from them.

In terms of saving time when troubleshooting stalled jobs, JAMS could do that. But we don't have all of our code set to send the output from a job back to JAMS. So in a lot of instances, we're still having to dig into the system, like Informatica, to get that log back and find out what's wrong. That is something that we, as a company, need to improve. It's not a lack of functionality on the part of JAMS.

We used it for scheduling our jobs. Our jobs were set up on different servers, which made the maintenance very difficult, and the main reason we switched over to JAMS was that we could have all our jobs from different servers in one single place. Secondly, we had many workflows that had to be triggered automatically, and JAMS was pretty much the tool that we wanted. We found it very useful to do workflow scheduling. 

JAMS provided all the audit trails. When a job failed, we looked into those trails and then went ahead and fixed those jobs right away to avoid future failures. There were many reasons for failures. Sometimes, it failed to connect to our Microsoft Exchange Server. At certain times, there used to be connectivity issues with our Microsoft Exchange Server. We changed the timing of the job accordingly so that there was not much business impact. That was one of the most common issues that we faced. The other issue was when a file was not received, and it was waiting for a prerequisite to be met. With the email feature that JAMS has, we made sure a proper notification email was sent to the right system instantly so that if a file is not received, the job does not fail. We had set up two hours of time for the job to wait for the file to arrive. That was a very good feature that we did not find in the other scheduling tools that we used.

JAMS saved time when troubleshooting stalled jobs. Because of its audit trail, we could directly go into the error log and see where the error was. With the email notification that we used to get for the failed jobs, the error used to be there as an attachment error log. In case we were not able to log into the JAMS system, we could directly open the log and find the error.

JAMS helped centralize the management of jobs on all the platforms and applications. We previously had different servers, and the maintenance was hard. Some jobs were on SSI servers, and some were on the Windows server. We also had jobs on other servers. We had at least four different servers. Everything was pretty disjointed, and this was our key use case to switch over to JAMS.

It's a full-featured job scheduling tool. The part that I liked the best was the support team. This tool was new, and we were all learning it and setting up the different jobs that were complex in nature. Their support team was very responsive in helping us out through the setup and resolving the issues. They have been incredibly awesome.

The email notification that we received was also valuable. I liked that part because if there was any job that failed, it was good that we were notified instantly. That's one part that we liked. Also, we had to run multiple interfaces on the JAMS server, and we were able to do that very easily.

It's the best tool to schedule jobs. It's super easy and super transparent. Once you know how to set up a job, you can easily train the users. It provides excellent visibility if something fails. 

The UI could be better. There were some things that were not quite intuitive, such as the search tool. When we tried to search for jobs, we had to clear the entire search and then go in and enter the new search query. That's something that wasn't intuitive for a new user.

Sometimes, when we used to search for jobs, it did not give us the status. There was system slowness or something like that. I am not sure if that had to do with JAMS, but that was something that we noticed.

We used it for almost two years. 

It's very stable.

Customer support was the best part of JAMS. When we needed instant help, especially when something in production failed, their support team was excellent. I would rate them a nine out of ten.

Positive

We had separate systems for scheduling. We did not have a single centralized solution, and that's why we went for JAMS, but now, we have moved to a different platform, which has an in-built scheduling system. The usage of JAMS is very limited now. Our IT team uses it, and I use it when there is a failure and I get notified.

We evaluated a couple more schedulers, but JAMS received the highest score overall. That was the reason why we went ahead with it. We did the initial feasibility and analysis of various different tools. There were about three solutions that were short-listed, and out of those, JAMS made it.

We are not using JAMS much now because of the new platform, but based on the time for which we used it, I would definitely recommend it to others. We were pretty impressed with it because we were not sure how much to expect from this job scheduler. We were very happy with it.

It's definitely something that we can vouch for. It's an easy-to-use tool, and it's full-featured. There are so many other features that were shown to us during the demo. We didn't use all of them, but it does come with a whole lot of features. It's very stable. 

Overall, I would rate it an eight out of ten.

We have many batch jobs. JAMS really helps us schedule all the jobs and execute them one by one, or sometimes in parallel, on a daily basis.

We have two schedulers, a primary and a secondary, and we also have a few agent servers. All the jobs are scheduled on them to run.

JAMS helps save time when troubleshooting stalled jobs. Also, in the past, we tried different schedulers. We used to have agent jobs on SQL Server, and we used Windows Task Scheduler, but now we have just one tool. For troubleshooting and maintainability, I don't need to go to different places to find the answer. I just go to JAMS.

The scheduling and execution of jobs are the most valuable features. The scheduling is important because if there is a task we want to execute at 4:00 AM, there's no way we will have someone who can manually run the job. In addition, we execute 100 to 200 jobs per day, and manual intervention is not an option.

I can also set up a workflow that repeats, which is quite good. And if there's something wrong, it will send an email notification so that we can look into it.

Most of the jobs are very critical to our internal business operations. On one hand, they need to be executed, and on the other, they need to be completed within a certain timeframe. JAMS helps split jobs out to our different agents to complete. That's really helpful.

The solution is good, it's reliable. But sometimes the UI is not the most responsive I've ever used. But because it does its job, I don't complain.

I've been using JAMS for about three years.

In general, it's quite stable. I don't need to worry about it 99 percent of the time. And because we have an HA setup, it's quite reliable. 

The scalability is good. If I have, say, two agents at the moment but I think that's not enough, I can just purchase more licenses and it will support more agents. We currently have six agents.

When I have an issue that I don't know how to fix, I just send an email to them. They are very responsive and knowledgeable. They always fix the problem for me.

Positive

Before using JAMS we used Windows Task Scheduler, but it's not a high-availability setup. If that server is down, jobs won't get executed. With JAMS in place, if the primary scheduler is down, the secondary will pick up all the scheduling responsibility, so we don't need to worry. Even if it is an agent, the job will be executed on other agents.

We had a consultant onsite to help us set up, so it was okay. We migrated jobs from Windows Task Scheduler, or agent jobs, to JAMS. It was not time-consuming, but because we have a lot of jobs it's not like the migration happened within 30 minutes. It took some time, but the process was simple and straightforward.

There is a bit of a learning curve to JAMS. It's not like you install it and it will be up and running for you. You need to learn to use it properly. Otherwise, you may run into issues. We engaged a JAMS consultant who gave us some training. It was expensive, but it was quite useful.

It's expensive, it's not free, but it takes care of my concerns. That is a form of ROI.

It's expensive, to be honest, but it does the job.

I haven't used another scheduler in several years, but compared to the one I last used, JAMS is better. It's more reliable, and that is actually the most important thing.

JAMS' ability to handle exceptions is not the best, but it's good. Don't expect any tool to be perfect. You need to make sure your internal program works together with JAMS to deliver the best solution.

What my team needs are tools to reliably execute all the jobs, minimize the risks, and support high-availability. JAMS does the job.

We use JAMS for file transfer, but instead of using JAMS file transfer, we have a script, a CMD file, which we schedule and configure to use either WinSCP or Ipswitch WS_FTP Professional. It will use either of those to send and receive files. We use it for scheduling file transfers.

It's deployed on AWS.

JAMS saves us on the order of thousands of hours per year.

I can create new jobs and schedule them based on time, based on a file trigger, or based on an email trigger. I'm happy with all those abilities.

The interface is good, and it's very easy to define and create jobs. If a job is not running or there is an error, the solution will send an email. That's all very good and very useful.

One issue which can prevent jobs from running is when a script gets into a loop. Suppose, using WinSCP, that the script connects to a particular vendor but that vendor has changed its server security key. I have to manually accept the new key so that it trusts the new server. Until that happens, the job will be stuck. It retries without end. JAMS will not kill it, even if it is running for, say, four days. We will only realize there's an issue on Sunday when there is a reboot for all the Windows servers, including JAMS. The reboot will kill any hung threads, and then we know something was stuck for days.

I think there is a way to configure JAMS so that if a job is running for so long it will shoot out an email saying, "This job is still running." I pinged support about it a long time ago and they said something like that to me, but I have not been able to configure it yet.

Also, I'm not sure if they have fixed it in a newer version, but there is no global search in the version I have. If I have multiple sub-folders that are named for business units, like HR or IT, and I have to search for a job, I cannot search from the top. I have to go to the HR folder to search for a particular job, or to the IT folder. It would be good to have a global search, where I could search from the top, rather than having to go into sub-folders.

I've been using HelpSystems JAMS for more than a year now. I'm the only admin for PSEG.

I'm exploring JAMS as we go. I'm trying to find more time so that I can explore all the other options it has, such as SAP connectors, so that I can suggest solutions we can use.

We have used their tech support a few times and they were very good each time. They were very responsive and very quick.

Positive

This solution replaced another tool we had before, called Apps15, which crashed one day. We migrated whatever we were doing there, all the CMD scripts, to this. Once we switched, we liked it and it has become one of our very important utilities for all the file transfers between our company and its vendors. We use it for multiple file transfers every day, whenever there is a financial transaction with many files created by SAP and other applications.

It saves us time and it is not an expensive solution for what we are doing. 

Maybe in the future, when we integrate with SAP and other tools, it might be a little costly, but it's still a very cost-effective solution. It's very good.

There is an application called Maestro, but that is built into SAP. In comparison, this is a comparatively very simple and smooth application that takes less time to configure. Maestro and XI are for internal transfers only, while JAMS is the main, approved solution for doing external file transfers. It is our enterprise file transfer tool.

It's a nice tool for scheduling, but make sure you are familiar with all the connectors. It can connect to and integrate with multiple applications. We have the SAP Job Scheduling Service doing its work, but JAMS can also do the SAP portion. Instead of having multiple tools, if you look at all the features that JAMS has, it might be able to replace the other tools so that you just use one.

It's a very good solution. Even my director was very happy with it.

It is our enterprise job scheduler. Every batch job that runs in the company runs on JAMS. 

It helps save time when troubleshooting stalled jobs. It has full logging. You go into your single pane of glass, you see all your failed jobs, you click on the job, go straight to the log, and you see what has gone wrong. And if something fails in the middle of the night, with the targeted alerting it sends an email or an SMS and does all your on-call for you. We've been using it for so long that it's hard to say how much time it saves us. But it's probably fair to say it quite easily saved us a day a week, and even more. The time saved could easily be the equivalent of one FTE. And that, of course, allows that FTE to do other work that's beneficial to the company.

One of the most valuable features is the natural language selection. That means that when you are scheduling a job, you've got more flexibility than anything else I've ever come across in the industry. You can not only tell it to run something daily or on a specify a day of the week, but you can specify "the first Monday of the month," or "the second workday of the month," or "the second business day of the month," or "the last business day of the month," or "every other Tuesday." The flexibility in the scheduling is because of JAMS' natural language selection. It's better than anything else on the market that I've seen.

The ability to change jobs is the stock standard for a job scheduler, but JAMS has the ability to allocate resources. We mainly use that at a global level. If we are doing scheduled maintenance, for example, we can halt all jobs. We can set the resource level to zero and no jobs will run. That way, we don't have to go through turning off schedules. For maintenance windows, it makes life an absolute breeze.

The alerting in it is really targeted. You can set a hierarchy of jobs if you like. There is a global level, obviously. But underneath that, you can have folders. We set up those folders at a functional level within the business. For instance, we have a folder for our finance jobs, another for our compliance jobs, and another folder for our equities jobs. At that folder level, you can set specific alerting so that if jobs in a given folder fail, certain people are alerted. You can also set security at the folder level, so that only people in those areas can go set them. That means that the alerting and security can be set at a very granular level.

Another great feature is the full auditing capability. If anyone makes a change to a job, you can see who's changed it and when. That full auditing capability is huge for compliance. And you've got version control, as well. If you make a change to a job and it fails, all you have to do is revert back to the previous version and you're back in business.

In addition, it's built on .NET. If you're a Microsoft shop, PowerShell is exposed natively and seamlessly integrates with it, which is brilliant. We use an awful lot of PowerShell in our organization because we're a Microsoft shop.

But it can run agents on any operating system and it can run all types of jobs. The execution methods it has are amazing. It can run stored procedures, SQL Agent jobs, SSIS packages, batch jobs, Linux jobs, and Oracle. The number of execution methods is huge and it runs just about any type of job you would want to run, and on any platform, which is also huge.

JAMS is also very intuitive and easy to use. It doesn't take a lot of work to set up and get started with it. It integrates natively with Windows Workflow Foundation, so you can build quite complex workflows, with if-then-else structures, and you can run things in parallel or in sequence. It really is a very feature-rich product but it's also very easy to use.

In addition, it helps centralize the management of all jobs and all your platforms and applications. You have a single pane of glass where you're looking at everything. If your organization is big, you might have multiple administrators. In that case, you set security at whatever level you like and certain people can only look at certain jobs. In my case, because I'm effectively the administrator of it in our organization, I see everything. But that one pane of glass for a whole organization is its great strength.

The only thing that they could improve on is the fact that they don't have a browser version of JAMS. They've got all the bits and pieces there if you want to build your own web version of it. It does come with a web client, but it's pretty clunky. They could improve on that.

I have been using JAMS since 2009. I was the first in the Australasian region to implement it. We're currently using version 6.5, but we're in the process of upgrading to 7.3.

The stability is really good. They do have a failover solution, which we're not using. We are just using the standalone, with a single server, but with no problems at all. We have never missed a beat.

We haven't had a problem scaling up. We have over 2,000 individual jobs, and we run 25,000 instances of those jobs every day. We plan to increase our usage as this is the only solution that runs jobs in our company.

All of IT uses it to schedule our jobs. And because of the security aspects, we make ad hoc jobs available to end-users as well. They can go in and all they're able to see, and run, only their ad hoc job. So about 50 out of the 350 people in our organization are using it.

The support is terrific. I've been working with these guys for 12 years and, as often as not, they've come across every problem that I've come across. I'll say, "Oh, listen, I've got this problem," and they'll say, "Here's a piece of code you can run. Here's an example where one of our other clients has done it before and we helped them do it." The support is brilliant; really good.

Positive

When I started with this company, they didn't have JAMS. Because I'd used it at a different company, the first thing I did when I got here was to say, "We're putting this in," and they did. They were running jobs via SQL Agent, as well as Windows Tasks Scheduler, SQL Server Reporting Services schedule, via Linux cron, and someone had even built an in-house job scheduler. Back then, when a job failed, remediating it was an absolute nightmare because nothing was synchronized. There were no dependencies on any of the jobs.

All the monitoring was done manually before, in our organization. Any company of a certain size should have an enterprise job scheduler. If you don't, you're just kidding yourself. You are making a rod for your own back, because someone has to monitor things, whether it's SQL Agent or Window Task Scheduler, to make sure the jobs are all working properly. Because it was manual, things would get missed and it was a nightmare.

The initial setup of JAMS was very straightforward. It was really good and their support staff was terrific in helping with that as well.

You get it up and running in a day, if you've got your servers built. It's a matter of provisioning a server, making sure you've got your service account set up, database ready to go or your database server provisioned. As long as you've got all the bits and pieces, you could be up and running in an hour, really.

ROI is hard to quantify. But whereas in the past we might have had one or more people monitoring batches and remediating failed batches, JAMS does all that now. It frees up one or two people. It's been an absolute no-brainer for us. It's worth its weight in gold and we cannot get rid of it now.

There was a price hike recently, which makes it a lot more expensive than what we are currently paying for it. You can do an enterprise license, which is probably the best value. But it's certainly a lot cheaper than Tivoli and Control-M. In comparison to them, you get a lot more bang for your buck. You get pretty much the whole functionality and more, in some cases, when compared to Control-M, but at a fraction of the price.

Before coming across JAMS, I had worked in bigger organizations that used Tivoli and Control-M. They are what I would call your "Tier One" solutions. Very big companies use them, although I don't know why they do, given that they're super expensive. Both of them are very feature-rich products, but in addition to being very expensive, they're very complex to set up. They also require a very heavy touch to maintain and administer. JAMS is easier to set up, much cheaper, and much easier to administer. 

There's another product called ActiveBatch, which is what I would call "Tier Two," because it's not as expensive as Tivoli and Control-M. ActiveBatch is in the same category as JAMS, price-wise. It has a nice drag-and-drop interface, which is something that JAMS doesn't have, but it's a lot more complex to use and not as intuitive.

Give it a go. Compare it to everything else on the market and, in terms of bang for your buck and the features you get, I would be very surprised if anything even comes close to JAMS.

You put an agent on every box that you want to run a job on. It's not agentless. But, as I said, you can put an agent on a Linux box or a Windows box or whatever other type of box you have and run jobs on any type of OS.

JAMS stays well ahead of the curve. I've been using it for 12 years and I still love it. I've recommended it at every company I've worked for.

We have a lot of automation between picking up files and pushing them to our dealer portal and to vendors in the cloud. We also use it so that vendors can place files in folders. In addition, we automatically email statements and inventory reports.

We have some jobs that run once a day at a certain time, but we have many jobs that are set to auto-run if a file shows up. When the time changes or a batch job on another server fails and we restart it, we don’t have to follow the job to the end. JAMS just grabs the file when it shows up and sends it. I love that.

We have over 50 jobs running daily to manage all the integration of our systems and we don’t have to monitor these jobs. They just run. In addition, JAMS centralizes the management of jobs in our environment and this has streamlined our monitoring.

The solution saves us about four hours a week in troubleshooting time and has helped free up about eight hours a week of IT staff time.

Among the most valuable features are

• the ability to define autorun jobs to pick up files and push them when they show up
• the scripting 
• PHP
• the timing.

All of these are perfect.

We also use the solution’s Interactive Agents. If we need to push something to our dealer portal, we can just drop a file in a folder and it goes. Running interactive tasks helps me users focus on business processes since I don’t have to take care of running the jobs manually.

Another useful feature is the solution’s ability to handle exceptions. If there are errors, we get notifications. 

The code-driven automation for handling complex scheduling works great. We have reports that come out and we have programs that will bust them and email them to our dealers by dealer number. JAMS helps with automation.

If there were a softcover book on how to really take advantage of all of JAMS' tools, I would buy it. I do better with training books than online searching, so a book would be helpful. I would read the whole thing and learn as much as possible about the product.

I have been using JAMS since February of 2019.

It is very stable. The only time it stops is when the server is rebooted and then the services are restarted.

It is very scalable and we really use a lot of what JAMS offers.

Technical support has been very helpful and that was particularly true when I hired a new programmer.

We used Freebyte and we needed to move off of that product.

I didn’t do the initial setup, but I didn’t hear any complaints from my programmer about it.

Initially, it took a couple of weeks to get all the jobs set up. But we have added so many more because the software has so many great features. We didn't do a migration from our old solution, we just keyed in all the definitions.

We have two people using and maintaining JAMS, but you don’t need everyone in the company setting up automated jobs, just the programmers and integrators.

This is a good product at a fair price. In addition to the standard licensing fees, there is an annual maintenance cost.

We looked at other options, but this was the best.

Consider how much integration and automation you require. This product is very robust.

Overall, the product is excellent.