JAMS Reviews

We run thousands of tasks for various purposes, including data manipulation, human resources, data flow, data management, and scripting. We use the solution for any task involving data management that must be scheduled.

The product gives us an excellent idea of what is happening and when. We have much control over job scheduling, and the workflows work very well. We've also built a lot of complex processing in the workflows where we can configure tasks to run at certain times or only when specific conditions are met, such as if another job succeeds or builds a particular file. The control JAMS gives us is outstanding.

JAMS helps centralize the management of jobs on all our platforms and applications, as it's all in one console. This is very important because we don't need to go to 50 different servers to get the big picture; instead, we can see it from one.  

The solution helped eliminate data slack across our applications; we have much control over the timing and sequencing of jobs, so the data is available precisely when needed. If we can determine when data is required, JAMS can help facilitate that. This availability is essential as data timing is central to many critical applications. 

JAMS saves us time when troubleshooting stall jobs because it's a centralized console where we can see all the failed jobs together and access the logs. Occasionally, we have situations where 20 or 30 jobs fail simultaneously, and we can manage it all in one place, which works very well. The time saved is about four hours per day. 

The product helped free up our IT staff's time, and the team would be larger if we didn't have it, which also frees up time. Using JAMS saves approximately 50% of our time.  

The most valuable feature is the easily accessible data in the database because we run a lot of SQL scripting against the database.

The workflows are easy to build, and we have a lot of control over how, when, and where jobs will run, which gives us a lot of flexibility. We've been able to do everything we want in JAMS at an excellent price. We've used the solution on many different servers for many applications, so that worked well.

JAMS helps us be aware of and handle common issues that can prevent our jobs from running. We receive emails that show logs from the application, which gives us a good picture of the situation in a failure, with essential information, including the problem and what we need to do about it. 

The solution's ability to handle exceptions is complete, and we have no problems at all with that. 

The tool's code-driven automation for helping us handle complex scheduling requirements is fantastic. It addresses advanced scheduling in our workflows very well and allows us to factor in sequencing, time, dependency on other jobs, etc., giving us great flexibility. This is important to us and a significant part of the solution's capability. If we didn't have JAMS, we would have to build our own mechanisms to manage job sequencing, but JAMS provides that capability in a straightforward WYSIWYG interface that works well. 

When looking at a folder in JAMS with many jobs, it would be good to have better information in the list display of what's inside those jobs. We get some information, but other important details are missing.

Sometimes it's difficult to find which workflow or workflows a job is in which could be improved.

I've been using the solution for about ten years. 

Overall, the solution is stable, and that improved over time. We had the occasional issue, but those were more to do with factors on our end than with JAMS. For example, we had the JAMS database running on a very slow server, and we sometimes ran out of server space, which isn't an issue with the solution. When we run out of room, we have to restart JAMS, and it doesn't recover particularly well, but this doesn't cause too much of a problem.

JAMS is highly scalable; we run tens of thousands of jobs daily, and there seems to be plenty of room for more. We have about 50 total users in our company. 

The tech support is fantastic; they're highly responsive, skilled, and knowledgeable. We usually get a good response within an hour when we contact them. We contacted them by phone and used screen sharing when encountering nasty problems. In one case, they spent several days assisting us through a big issue by phone. They've been very supportive and knowledgeable, so I rate them ten out of ten.

Positive

I don't remember what product we were working with before JAMS, but when we switched, it was like a breath of fresh air, as the previous solution was very difficult to work with. 

The initial setup was very complex as we had a lot of jobs, and we worked with JAMS Professional Services. The most significant factor is the learning curve. Now I'm familiar with the product, I could go into a new site and set it up within a few hours; experience is an important element. One staff member is sufficient for maintenance. 

I haven't been involved in the financial side for several years, but we buy one host and unlimited agents, and we get a reasonable price for that. We're happy with the amount we pay and the scalability it provides.

I rate the solution ten out of ten. 

JAMS eliminated virtually all our other monitoring tools, as 99.9% of what we do is with the solution. We do a few minor tasks in Linux for crime jobs, and we have to use Task Scheduler in a few situations because we can't have centralized processing. We use JAMS 100% where we can.

My advice to those evaluating the solution is to set up your server to run the jobs you need to run beforehand. Those are generally already in place if you're switching from another tool. JAMS is a very lightweight application, so you don't need a lot of processing power. Dictate a host and a failover host server, and you can build a development environment. Still, it is optional as there are decent ways of promoting code from development to production. The solution is relatively straightforward and lightweight.

We implement Fortra's JAMS for our clients, utilizing their existing scripts, batch jobs, and stored procedures. We define all batch jobs within JAMS, providing our clients with a single console to monitor and track the status of their running jobs.

Integrating JAMS into our existing IT infrastructure is a straightforward process. JAMS provides templates for common execution methods like command jobs, SQL jobs, and SSH jobs. We need to define the location of the jobs on the agent server and update their schedules based on our existing workflows.

Our clients have many departments, each with specialists for different tasks. Some manage SQL queries, others handle batch jobs, and others deal with ongoing jobs. This requires them to access various servers simply to check if jobs are running successfully. JAMS provides a single point of access, allowing them to monitor the status of all jobs from one location. This fosters shared knowledge among different departments. Previously, individuals might not know how to check the status of specific jobs, like SQL queries, leaving them in the dark about their success. JAMS empowers all IT personnel to view the status of any job, enabling them to track progress, identify errors, rerun jobs, and resolve critical issues.

We receive immediate notification of errors and can view them on the monitor. However, while the JAMS log reflects errors within the job itself, it often lacks the information needed to resolve them directly. As a result, we still rely on programmers or developers to interpret the logs and assist with troubleshooting. Nevertheless, the notification system provided by JAMS is a valuable tool.

JAMS helps us schedule jobs efficiently by notifying us of long-running jobs and allowing us to set jobs to run in sequence.

The JAMS central management console provides a convenient single point of access for monitoring all running jobs. This allows for clear visibility into job statuses, enabling clients to promptly address both successful jobs and those encountering errors.

JAMS helps eliminate data slack across our applications. We can react to errors so the data doesn't get stuck on the server.

JAMS helps cut troubleshooting time for stalled jobs by 50 percent. Logs stored on JAMS are based on the project's allocated budget. For troubleshooting, we can access the JAMS server. However, previously, resolving issues required accessing the server hosting the specific job and finding someone familiar with it. JAMS's primary strength lies in notifying users and pinpointing the error location within the job, streamlining the troubleshooting process.

JAMS helped eliminate the need for multiple monitoring tools. Since our clients no longer use task schedulers, there's less confusion; some people found the Windows scheduler difficult to understand. JAMS provides a user-friendly way to view job schedules. We provide an initial transfer to familiarize clients with the monitor's components. Now, with JAMS as a common tool, teams can easily understand each other's jobs, regardless of whether they're front-end or Windows scheduler-based. This is a significant improvement.

By using JAMS, IT personnel can focus on other tasks without needing to actively monitor their servers. When an error occurs, JAMS automatically notifies them via email or through the JAMS website, allowing them to address the issue promptly. This not only reduces the time IT personnel spend on monitoring, but also provides them with peace of mind knowing they'll be notified of any problems.

JAMS handles job dependencies and error recovery in our environment well.

While I appreciate the other features, the agent stands out for its ease of installation and configuration for JAMS monitoring. We can define thresholds to detect jobs running longer than usual and receive notifications when that occurs. Job monitoring is also a valuable feature for our clients.

While JAMS's cross-platform capabilities are good, my only concern is the need to download an ODBC driver to connect to specific databases. It would be highly beneficial if JAMS natively supported these connections, eliminating the need for separate driver downloads for each database.

With no programming experience, I find JAMS code-driven automation challenging due to the required PowerShell scripting. While JAMS offers helpful guides, the technical barrier remains significant.

I have been using Fortra's JAMS for three years.

JAMS has been stable with no bugs or major disruptions. I would rate the stability of JAMS nine out of ten.

Scaling JAMS is easy and user-friendly to do. Minimal configuration is required.

The technical support is good and quick to respond.

Positive

The initial deployment is straightforward, requiring only a few clicks and some data entry. It took two weeks and involved two IT personnel.

Our clients have experienced a return on investment by using JAMS, thanks to the improvements it has brought to their processes.

JAMS is priced competitively compared to similar solutions and offers flexible licensing options to cater to user needs.

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

We have three JAMS users in our organization and over 50 in our client's organizations.

I particularly recommend JAMS to our clients in the financial industry. It offers valuable features for monitoring job execution, receiving error notifications, and integrating seamlessly with other applications.

I use JAMS to run repetitive tasks that I need to do each day, like loading database entries, performing backups, and building daily reports. The organization uses it for complex workflows, sequences, and ad hoc jobs.

We aren't using JAMS for much complex scheduling. We schedule tasks on weekdays, but we aren't using a calendar to specify holidays. That is something on the to-do list. We want to have it scheduled to run on the work week except for holidays or other exceptions. However, it can run jobs based on sets of schedules and sequences. 

We consolidated several Windows scheduling servers into the dev and production JAMS environments. A few servers still have custom-scheduled tasks, but we moved most jobs from Windows Task Scheduler to JAMS.

JAMS helps us troubleshoot stalled jobs. For example, if I get a work ticket to check out a failing job, it's easy to look at the log file tab on the job and quickly get the details I need. Error logs are verbose and well-written, so I know what is wrong, whether it's the credentials or a file that can't be found. 

If a job fails or there's a trigger for a bad read text pattern, JAMS will send an email alert. I usually don't hear or see the functions, and I don't know if anybody is watching the monitor tab in the scheduler to see if there are any failing jobs. Aside from any email alerts when a job fails, I have found no real dashboards—at least not with 7.3. It may not be the case with the latest version.

It hasn't enabled us to eliminate monitoring tools so far. Only a few teams use JAMS to send custom monitoring reports, and additional software comes with the VM build. It hasn't been removed. All of the organization-wide tools stay, but some of them might be utilized less. If those teams are using custom JAMS reports more than other tools, it's probably because they could tailor their JAMS script to display the information that's most relevant to their team's needs. 

JAMS provides some flexibility in that aspect. They can run jobs to check the status of the database or Windows services. It gives them the freedom to build those tasks into a sequence or a workflow and get that report back fast instead of using a tool like SolarWinds. You'd need to create a dashboard and find an admin person, and that'll take time, whereas they can just do this quick job, and it gives them the exact information they want. JAMS frees up some at-instance time. Job automation, scheduling, and the ability to pause while other jobs finish saves time. 

I like how you can add new execution methods on the fly. It isn't overly complex to add Python script support to an execution method in the JAMS system. The scheduling is excellent. You can schedule a maintenance window and take that resource unit out of everything. It halts all of the jobs. 

We did that when we upgraded the last time. It's helpful because we don't need to worry about upstream and downstream jobs or any triggers and kickoffs. I also like that the JAMS uses PowerShell and has a PowerShell module. 

Regarding JAMS' exception handling, I will say that the person scripting a job should try to catch those exceptions and do their own internal logic for it. JAMS will generate an error if I write a script with an exception, and it'll display that error in the log. JAMS catches it. 

I would like to see the ability to interface with Microsoft group-managed service accounts, but they're still in the research phase. They need to ensure everything's legit and safe. The report designer and dashboards could also be improved. We're running 7.3, so I don't know if they have updated the reporting in 7.5, but I think the reports and dashboards could be better.

If I open one of JAMS' pre-installed reports but don't launch it on the server where the scheduler's installed, it will take forever to load through our VPN connections. It may be related to how we have our servers set up. I don't know if that's an issue with JAMS or not, but I need to be careful about where I open the report designer. Otherwise, I will sit there with an endless blue circle. I can open it on my workstation or use a remote desktop to access the server and open it via that. 

It would be helpful if the data in that report designer could be leveraged in Power BI. I don't know if they have that already, but that could be one way to improve the reporting and dashboards. Maybe there's already a way to do that. I should look at their website first or contact support because Fortra's support is fantastic and always super helpful.

The company has been using JAMS for about two years, but I've only used it for a year and a half. 

JAMS has been pretty stable. We have a single instance, so we're not running high availability, and the uptime has been solid. We have only had to go down to do scheduled reboots for server patching.

It's easy to scale the VM vertically where JAMS is deployed. To scale horizontally and install more agents, we would need to buy more licenses for the agents. It's a matter of contacting support and having the money to buy more licenses. It isn't too difficult to contact our account rep. We don't have problems buying licenses for additional agents. 

It would be cool if we could install multiple agents and have the scheduler server ensure we only use the number of licenses or agents allotted under our licensing agreement. For example, if our prod environment has licenses for three agents, we could deploy six agents that are available to run jobs, but the scheduler would ensure that only three agents are active simultaneously within that environment. That would be an interesting feature.

I rate Fortra's support a ten out of ten. The turnaround is always quick when I email them. They're knowledgeable about it. I can send them a few screenshots and logs, and they respond with some suggestions. They typically resolve the problem on the first try. I haven't used their telephone support, but other people have told me that works just as well.

Positive

I wasn't around for the initial installation when the company first purchased JAMS, but I was indirectly involved with the upgrade from version 7.2 and to 7.3. The upgrade process was extremely straightforward. Fortra's support provided a Wiki article to walk us through it. We backed up the files and performed the steps. You go through the installer to upgrade it.

I rate Fortra's JAMS a ten out of ten.

Our primary use case is for file automation: detecting the presence of files, moving files from one system to another, doing FTP uploads, FTP downloads, and a large number of custom execution methods. Custom execution methods are a way to create your own code that extends the JAMS toolset.

For example, in one of our systems, it has a tool that needs to be run in order to import a file into that system, which is very proprietary. However, those file import definitions are dynamic inside of the system; you could have 100 different file formats. We created a custom file import/export method for our system. The JAMS job calls the other system's API. The JAMS job definition tells it the path of the file to load and what parameters to use. It then reads and displays the remote system's API return results. Custom execution methods are the meat and potatoes of what we use JAMS for.

We have a single production JAMS server that serves as the primary JAMS node where most of our work is done. We have an agent server where the primary node issues some job commands to run on that agent. Then, we have a test JAMS server which we use when we are testing execution methods and other things. We have plans to stand up a failover server, but have not done so. The back-end database for our JAMS production system is Microsoft SQL Standard Edition and all our servers are on Windows.

Automation is subject to a volatile environment. That's reality. You have a client that provides you a file with the wrong naming convention or in the wrong format, or they are supposed to give you a file at 8:00 AM every morning, then one day they simply don't give you that file. Those are the sort of nuisances that create headaches for your production staff as they are trying to work through and detect them. Sometimes, they will fly under the radar, especially if you have a less sophisticated job scheduler running batch jobs, like Windows Task Scheduler. They run at a certain time and are expected to just work. However, maybe two days later, someone finds out that the file, which we normally get every Monday, was not presented to us. Those are the tricky little devils that will get you.

What we do when we develop a JAMS file workflow is we have certain checkpoints that we put into it. If we have a job that wants to run it at a certain time and expects a certain file to exist, we will have the job specifically check for that. If the file doesn't exist, it will create a very specific, actionable alert. We design that to go out to our file processing operators who can respond accordingly by contacting the client. When we are doing an export, if we want to run a file out of our systems, the job that runs the export could detect there were no records that day. It might report that back, then we can act on it. Or, perhaps after the export job run, you could have a follow-up job that checks to see that exactly one and only one file is available in that export destination.

You can't necessarily prevent environmental issues from happening. You can't expect every client to always do what they are supposed to do and give you what they are supposed to give you every day. However, when they don't, at least you can know about it as soon as possible and take action on it rather than finding out about it by accident sometime down the road.

It has drastically improved our capabilities to scale our automation. Before JAMS, there were a lot of manual processes. We had a couple of operators who spent all day doing that. A lot of the time, with human intervention and manual processes, it is as good as the person following a procedure. Human error is a big problem.

Shortly after we adopted JAMS, our file volume started ramping up. The number of files, reports, and other processes that we have had to automate has grown exponentially. We have been able to keep up with that load. JAMS has been able to scale up our organization's scheduling and automation without adding staff. The people who previously did these manual processes are now trained on monitoring the automation and scheduling of those processes. They only step in and respond to issues, rather than running manual procedures all day.

There are many platforms that an organization might use. We have Microsoft SQL server, Artiva, QlikView, and Qlik Sense. All those different platforms have built-in schedulers: SQL scheduler, QlikView scheduler, Artiva scheduler, and Windows scheduler. Without an enterprise scheduler, all those independent schedulers can only be coordinated by time of day. If you want to export a file at 8:00 AM, then set up a scheduled job that runs at 8:30 that loads that file into your BI tool, in theory that should work. However, that sort of time-based, unintelligent scheduling and coordination between systems falls apart when anything goes wrong. Let's say your 8:00 job should be done in five minutes and you have your 8:30 running on your BI scheduler. If that 8:00 job runs long, doesn't produce a file, or if it throws an error, then your BI scheduler doesn't know and just does what it always does. It runs its 8:30 job because there is no coordination. Now, users are wondering why they have a BI report with yesterday's data in it. With JAMS we have chain jobs together in a sequence. The first job throws an error so the second job never runs because there was a problem. An operator can resolve it and resume the sequence.

We have tried our best to consolidate our scheduling and not to use the Microsoft SQL job scheduler, BI tools, and built-in schedulers, but rather to use JAMS and create custom execution methods to schedule everything in one place.

The extensibility feature, i.e., the custom execution method ability, is the most valuable feature. We can write a C# interface using the JAMS libraries. We copy the DLLs for the client interface over to our remote desktop and JAMS servers. Then, any of our JAMS users can open up a job definition and see the control developed by our developers. When the job command is issued, it executes our developers' code.

I am happy with the exception handling, for the most part. When an exception occurs on one job inside of a series of jobs, it can make that series of jobs stop running, sending an email to someone to let them respond. There is also a monitor view where you can see everything that is currently running and any of the jobs that are currently in an error state. You can find them and try to rerun the job, or cancel it if the job doesn't actually need to be run.

JAMS will attach the console logs from anything that has an error on the email that goes to the operators. Also, inside of the job monitor, you can go to the logs and dig down into the details to see what went wrong.

It has the ability to use PowerShell to schedule jobs, enable, or disable triggers. The fact that they have JAMS PowerShell cmdlets is useful. This is not central to our use of JAMS, but I appreciate it. While they have extended PowerShell and created cmdlets, I tend to use that when I have to do things like kill all the jobs currently in the schedule, if something catastrophic has occurred. I use them on my test server more than production. On my test server, if I am running a bunch of tests and jobs, but I just want to wipe out the whole scheduler, then I can use a PowerShell command to do that.

From time to time, a job is executed and gets stuck in a loop. It gets hung. Maybe the remote system freezes up. Something abnormal happens. It is pretty easy to deal with those. You can see them inside the JAMS monitor because JAMS will automatically calculate the average time that it takes for a given job to execute as long as it has had a few successful runs. The JAMS Scheduler can predict what should take five minutes to run. If it is running for 30 minutes, there is a percentage that shows inside the scheduler that the job is now at 600% of the normal run time. So, you will see this big number, 600% and climbing inside the monitor. You can research that. You can go find the hung process on the source system and respond accordingly. You can set up jobs such that they send alerts or have runaway job limitations. I personally don't tend to use the runaway feature. Our operators notice and respond accordingly to long-running jobs.

The biggest area with room for improvement is the area that my organization benefits the most from using JAMS, and that is in custom execution methods. I happen to have a very good C# developer. Ever since we got JAMS, he has spent a lot of time talking to JAMS developers, researching the JAMS libraries, and creating custom execution methods. He's gotten very good at it. He is now able to create them and maintain them very easily, but that was hard-won knowledge. If I ever lose this developer, I would be hard-pressed to find anyone who could create JAMS custom execution methods as well as he can since there really isn't all that much help, such as documentation or information, available on how to create custom execution methods. 

I really think that they could benefit greatly by being much more transparent about C# development, maybe by making a JAMS cookbook or a developer portal where they could throw ideas at each other.

One of my complaints with the marketing around JAMS is that it says things like, "It integrates with Teams". They talk about integrating with a lot of things, but marketing doesn't tell you that they are talking about JAMS running PowerShell jobs. Since PowerShell can automate things like SharePoint and Teams, that is how marketing gets away with saying it has so many integrations. JAMS doesn't have as many built-in integrations as they advertise. I think they should build more of them, and improve on the ones they have built.

We purchased JAMS six years ago. I have been using it the whole time. I was involved in shopping for potential enterprise job scheduler solutions and selecting JAMS.

I would be hard-pressed to think of any occurrence that we have had over the last five years where JAMS has crashed, had any sort of catastrophic failures, or instability. It is a pretty rock-solid system. I am happy with it.

Scalability is great. It has the ability to add agents. We are a Windows shop, and at some point, I am sure we will expand and add more Windows agents. If we were running other platforms, IBM or Unix, then there are agents for that. A company a mix of systems would do well with JAMS because of that flexibility. The ability to have multiple servers and failover servers is a great benefit. Because we are a fairly small power user, we haven't had to really take advantage of that scalability very much, but we are glad to know that it is there.

It is used extensively across the organization in all our business intelligence reporting data refreshes, data warehouse SSIS packages, file importing and exporting, and file movement. We use it for sending automated ticket creation emails to our ticketing system.

The place where I have targeted for us to extend the solution's usage is in the Artiva systems, where not all jobs are scheduled inside of JAMS. There are still some legacy jobs that are scheduled inside of the Artiva's internal job scheduler. I plan on moving jobs into JAMS and making them JAMS jobs.

When I find room for improvement, I log a ticket with JAMS. So, I have logged plenty of tickets.

I would rate support as an eight out of 10, mainly for lack of documentation and support for the custom execution method development.

Positive

It has eliminated monitoring tools like the job schedulers, e.g., the SQL Server scheduler and Qlik Scheduler. You need to have special skills to go and investigate a job that might be running on those schedulers. We didn't have an enterprise scheduler before JAMS. So, I can't say that it eliminated a different enterprise scheduler, but it does prevent us from having train our operators on all the various systems' schedulers. That is one of the benefits of consolidating your scheduling down to a single enterprise job scheduler; you only have to train on one tool. Once a person knows how to look at the job run history, job logs, and job definitions inside of JAMS, they don't need to know how to do that on SQL Server. They don't need to know how to research a Windows scheduled task running a batch job and know where that batch job logs its results. All of that goes away because you can just look at that in one place.

My experience at a former employer was with Tivoli and Tidal job schedulers. Tivoli and Tidal were larger, more complex, less intuitive, and less user-friendly. We also didn't have the ability to do the C# custom execution methods that we do in JAMS. Also, the price was in a completely different ballpark. Tivoli and Tidal were much more expensive.

It was pretty straightforward. When we started with JAMS, we didn't even have SQL Server. It natively installs SQL Express for you, so you don't need to buy an SQL Server if you don't want to. You don't need to buy agents if you don't want to. You can have all the jobs running locally on the JAMS server. That is what we did for a while before we got the separate agent license. The amount of time to learn how to use the tool was not very challenging. It was pretty easy to learn.

The biggest challenge was when we saw and heard what we could do with custom execution methods. We knew we wanted to do it, but it took a long time for our developer to figure out exactly how to do it right.

The JAMS developer and I are the administrators of the system. We do the upgrades, the custom execution method development, create a lot of the job definitions, and help train people. 

There are two people that I would classify as operators. They monitor jobs. They respond to errors. They rerun failed jobs and move files. Also, if the client gave us a file named incorrectly, it would be their job to rename it, fix it, and tell the client that they did something wrong, then rerun the failed job.

There are about four other power users who create job definitions.

There are a large number of people in the company who might receive an email when a report is finished or be notified if there is a problem with a job that was created for their benefit. However, I wouldn't consider those people as users so much as they are people who benefit from the product. There might be 30 of them.

We have easily seen ROI. This is based on the fact that the number of jobs that we are running, the number of processes we have automated, and the number of new clients and processes that we've added since taking on JAMS without having to add staff has paid for itself in dividends.

Take advantage of its scalability. You can start small. The initial cost is very reasonable. Once you have started picking up the tool and adopting it, then you can scale up from there and buy more agents.

There are annual licensing and maintenance costs. If you add agents or servers, every one you add has an additional annual cost. Then there is the basic cost of any software, which is the server hardware and operating system.

Yes, I evaluated Tivoli, Tidal, and several other enterprise job schedulers. It has been five years so it's hard to remember specifically which others I looked at.

I have three examples of working very closely with enterprise job schedulers. If a company doesn't have an enterprise job scheduler, then JAMS is an easy choice. Really adopting the idea of using an enterprise job scheduler into your company culture is important. You need to move jobs out of all your other job schedulers and centralize them in JAMS.

Don't just use it to schedule jobs on one system. Don't just use it as a Windows Task Scheduler replacement. Don't just use it for batch files. Anywhere that you see a scheduler, you can replace that scheduler with JAMS. Get a good C# developer and start making your own custom execution methods.

Contact JAMS support and get your developers talking to their developers. That will help you get up to speed a lot faster. 

For anyone coming off of another job scheduler, like Tivoli or Tidal, I would tell them that they have made a good choice. This solution is just as powerful and much more cost-effective.

Lean into it. Really use it. Don't just use it for this and that. Don't have your other systems and job schedulers doing their own things like exporting files and then relying on JAMS a file trigger to detect the presence of that file. Have the JAMS scheduler kick off the job that creates the file. Don't do it half-heartedly.

I would rate it as 10 out of 10. Anytime that I am geeking out with other IT guys about their systems and processes, I always end up talking about JAMS.

We have a student information system (SIS) for education. We have 50 school districts that run on the same database, and they all can run reports through the GUI. JAMS manages the reports. We have a throttle so that they don't overpower the system. So, the stuff comes through the system and the throttle manages it, and then if there's a certain report that runs over, we can kill it. They can run it again with better parameters. That's pretty much the main use. We have a lot of nighttime jobs that we schedule through that as well.

It's deployed on our private cloud. We run our own server. In terms of its version, we're on the most recent version.

If JAMS has a deadlock, we get a notification. When there's a deadlock, it'll kill the job. If something runs too long, it kills it. We also have a throttle, which also helps the whole system to work. If we didn't have the throttle, it would be bedlam. It would be crazy. 

It absolutely helps to eliminate data slack across the applications. It'll kill jobs; it'll kill deadlocks faster; and it'll kill long-running queries. We can get in there, and where the software doesn't allow us to kill the job, we can get into the SQL Server, but JAMS is much cleaner, and more people can get into it without having to expose the database access to people. We can give them JAMS access where they can kill the job.

It saves time when troubleshooting stalled jobs because of the fact that more people can get into it without having the access to the backend. 

It has 100% helped to free up the IT staff’s time. Previously, there used to be two or three of us for monitoring, but now, we've boiled it down just to me. I get the notifications, and I handle them. It has absolutely reduced staff time.

The overall product is fantastic. I love it. It has been a fantastic, solid product. If I have one tiny bit of a problem with it, the support team gets in touch with me right away. I don't know if I've had another service that has been as fantastic as the JAMS support team. 

I would like a simple web interface that I could give to my team to go in and kill jobs or see why jobs died so that we don't have to drill down deeper into the application and know everything about it. It would be good to have a really clean web engine that would say here are the jobs running.  We can then click to see the time running and whether any of them fails and other similar things. I know they have one, but it's not very simplistic. It would be awesome to have a simple one. 

I have been using this solution for about 15 years.

It's 110% rock solid. JAMS has never failed us. It has been rock solid.

We only use it for one thing. I don't have any input on its scalability because we don't use it for anything else. We only use it on one platform. So, there's no centralization. We have one main application. It has the front end, the back end, the middleware, and all that jazz. All the jobs to maintain the software are run through JAMS.

We probably use the simplest features of JAMS. We have no complex code-driven things.

I would rate them a 10 out of 10. They get back to you faster than your mom will call you back. When we've had problems, such as if I've had a job that keeps on failing and then I say, "Here's the error code, and I don't know why it's failing," they're right back. They are fantastic. Although I haven't contacted them in probably a year, when we first started up, our software code was sketchy or a little weak, and it failed. JAMS was right there when we had problems with scheduling things. They were fantastic. Their support is amazing. The product is solid. It's as solid as it can be.

Positive

JAMS was our first and only one. I know they did a lot of research on it, and they picked JAMS. The whole state uses it. They picked it, and we didn't know. We didn't come from anybody, and we aren't going to anybody, that's for sure.

I've installed it many times. It's simple as a pie. With a few clicks, you are done. It gets done as fast as you can click. It's very simple. As long as you have all the parameters, a database, and your web front end, it's super easy.

Our licensing is pretty cheap because we have a state solution. So, we pay only $1,000 a year. 

We're a software provider for school systems. We are state-owned. There are 13 of us throughout Ohio, and we have a collective agreement with JAMS or a collective licensing through JAMS. Because we have so many licenses, we get a discount on the renewal, etc.

I would absolutely recommend it to anybody. If you don't give it a try, you're a fool. At least give it a try because you'll find that it's an easy install. It's an incredibly easy management tool to go around. The setup wizards are nice. It's a little slow on some of the history look-ups, and I don't know why. Other than that, it's very clean with a good front end and easy manageability.

In terms of helping us to be aware of and handle common issues that can prevent our jobs from running, we haven't had anything. It will kill a job if there's a deadlock, and obviously, we get notifications if there are bad parameters in the job run, but I don't have any notifications about not running because of permissions, low resources, or anything like that. We don't have that kind of thing set up.

I would easily rate it a 10 out of 10. With the stability and the support, to me, every day, it's a 10.

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.

Positive

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. 

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.