JAMS Reviews

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.

The initial use case is that we use it to centralize everything, including all jobs from across different environments. Our goal is to be able to do all of the maintenance centrally.

When our jobs run, our team handles the jobs and they are not assigned to other teams. The output, which is on the backend and put into the database, is available for everyone.

JAMS helps us to deal with the small issues that come up here and there because we implement notifications for jobs. Whenever a job fails, it sends a notification and most of the time, there is a setting in the configuration that has to be changed. We have JAMS configured in a data-driven setup.

Whenever a job runs, it reads the configuration settings that are specific to it. If ever there is an issue, it's typically because we have the wrong configuration. In cases like this, we tweak the configuration and then somebody runs the job again by right-clicking on it.

We have JAMS set up so that we are running two interactive agents. One is a scheduler and the other is exclusive for SSIS execution. These are important to us and without them, it's going to negatively affect the business.

The way that we implemented and use JAMS is in a centralized configuration. We don't have people running jobs on their desktop because it would mean that we don't have visibility of it. Instead, everything has been migrated to JAMS so that it can run centrally. If anybody needs to run a job or perform any execution, especially for production, they can do so in JAMS. Later, we can look and see who ran what jobs at what times, and if ever there is a modification then we will know who modified it.

JAMS is able to handle exceptions in different ways. The way that we have it configured is to notify us. The process may be retried several times and we can set the limit for this. We also configure what the delay is between retries. It will depend on the use case and how long it takes. However, if it fails then it has to notify another group so that they can take a look at what the exception was.

We have a job that is similar to a report subscription, and this is done for each of our 50 partners. Prior to JAMS, we were required to run 50 different jobs. As it is now, given that JAMS is data-driven, we have only created a single job. It is written as a workflow with those configuration items. We don't need to change the job or add to it. Instead, it reads the configuration table and runs the 50 processes right away.

If there is a process that needs to be disabled then we do so in the configuration table, and the workflow picks up the changes. Having a single job taking care of the 50 processes makes the system more flexible.

JAMS helps free up time for our IT staff because it's centralized and the logging is there. The time that IT spends troubleshooting a job has been significantly reduced. The amount of time it saves varies on a case-by-case basis. For a more complex job, it can save more time. If we consider SSIS, it has its own logging capabilities but it requires that somebody with the right permissions go in and open the logs. Not everybody has permission for that, so the job depends on perhaps a single person. Often, that person has several responsibilities and other things to do, so the task can take longer to complete. JAMS collects all of the relevant logs, and having them centralized means that several people can view them, rather than only those with that application-specific set of permissions. This is one of the reasons that it saves us time.

The most valuable feature for us is that it's DR-ready. With respect to disaster recovery, it has the built-in capability for failover to our DR site. If all of the required ports are open, it can be done seamlessly.

We test the disaster recovery capability every now and then because it is important for us to be able to failover to another site. As long as that works, if we have a problem then it's business as usual. A problem doesn't impede our work because there's no interruption in the service.

Writing the JAMS schedule is nice because we can use natural language in English. For example, we can specify days by writing "the first of March" or "the second of March". It's clear. Being able to specify the schedule in this way is good.

JAMS saves us time when it comes to troubleshooting stalled jobs because of the logging that it provides. It allows us to go to the execution history, look at the log, and find the problem. Even if the log is very large, it provides a path for us to follow and find what we need to look at. We can typically solve issues in an hour or less because of the logging.

The PowerShell integration is great. When there are things that we couldn't do out of the box, they have execution methods that we can use in PowerShell that make things more flexible for us.

The search capability needs to be improved because when we try to search for a job, it's hard to do. We have to know where it is. This is really the functionality that I think is lacking.

We have been using JAMS for approximately three years.

JAMS is a pretty stable solution that handles the resources very well. 

This product is highly scalable.

We have two people on the administration side and another ten people who are working with it. They are using it as part of their support role with the helpdesk. We also have a developer that creates the jobs, which are then scheduled by JAMS.

We will probably increase our usage in the future. Right now, we're implementing the web client of JAMS. When we get to the point that we are fully using it, including the web component, then that may be the time for us to look into expanding our usage. At this point, we want to be able to maximize the use of JAMS, and so far, it seems that there's a lot to JAMS that we haven't really used yet.

I would rate the support very high.

First, the response time is very good. When we engage the support engineers, they always know what to provide us with so that we can figure out what's wrong. Whenever we need to go to meetings, it's always a learning experience. They're very smart.

JAMS did not replace other monitoring tools and it was able to solve the problem that we had.

I was not the person that initially set up JAMS. It's not complex but that person didn't follow the procedure fully. When I took over the implementation and setup, JAMS provided a checklist. It was good because I was able to follow each of the steps. From what I can tell, in the initial setup, we didn't follow it to a tee, and this caused some complexity on our end.

The deployment took about a year in total, although in a typical situation, I think that two weeks would be enough time to implement it. Depending on how much work needs to be done, it may take a month to complete.

In our team, we have a two-week scrum process and it would be quicker for us to do. Our security and infrastructure are also different than it is in the rest of the organization. For example, we can set up our own VM, database, and scheduler if they are not already set up.

JAMS provides a list of the best practices with regard to security. 

We have two people in-house that are responsible for maintenance.

There are a lot of features in JAMS that we haven't used yet. For example, there is a special calendar and we haven't even tried to utilize it. However, we would like to eventually use it to its full potential.

In summary, this product is top class. I would like to commend all of the engineers and support team at JAMS, and I highly recommend it to others.

I would rate this solution a nine out of ten.

We use the solution for workflow automation.

The planning capabilities are most valuable. Additionally, it is very easy to use and is efficient.

In the future, it would be beneficial to have more integration.

There could be a better simulation for banning the termination. You have to simulate every one of the processes in order to have an idea for better planning. This kind of simulation is broken and needs improvement.

I have been using the solutions for approximately five years.

Most of our clients are large businesses and they use the solution daily.

The support we have received has been very good.

I have evaluated Gems and Control M in the past.

I recommend this solution to others.

I rate HelpSystems Automate Schedule an eight out of ten.