JAMS Reviews

We utilize Fortra's JAMS to automate tasks within our banking organization.

We utilize a range of jobs for different tasks. Specifically, I possess 1,500 jobs that handle file movements. Additionally, we have approximately 600 SQL jobs, consisting of SQL commands, SSI jobs, and various other types of jobs. Our jobs run on Linux and Oracle, and perform functions such as encryption, decryption, zipping, unzipping, and uploading or downloading through SFTP or FTPS. Furthermore, we employ some visual basic jobs.

Fortra's JAMS enables us to identify and address common issues that may impede the execution of our jobs. This is of great significance to our organization.

The interactive agents are critical components since we cannot use a JAMS server for SQL jobs due to permission issues. Therefore, we delegate this task to another server. However, this causes the job to be offloaded from JAMS' scheduler, hence the need to distribute the process to another server.

We centralize all of the tasks in our bank, which include Microsoft Windows tasks, scheduled tasks, batch jobs, and scripts. This is a replacement for the SQL job that we previously scheduled across approximately one hundred servers. By centralizing and scheduling these tasks together, the entire process is visible to everyone in the bank. This is critical because if the system goes down, it would affect all banking processes, including ACS payments, ATM, reporting, and other functions. This software is essential for the bank's operations, and without it, we cannot function properly.

Fortra's JAMS helped us centralize job management across our platforms and applications. This is critical because we schedule tasks across multiple applications and operating systems, using triggers and start dates to coordinate their execution. Managing permissions has always been an issue, but we've now centralized permissions for all jobs based on department.

Code-driven automation assists us in managing complex scheduling needs. The system includes a built-in template form. Fortra's JAMS provides the ability to improve the form within the code. This feature is beneficial because we can create our own custom scripts and add them to the system. However, it would be even better if we could add additional forms to the system.

Fortra's JAMS helps to eliminate data inconsistencies across our applications. Essentially, all of our activities occur at the system level, primarily through batch processing. We are not end-users and they do not directly access our system. Instead, we upload reports to SharePoint or similar systems, from where end-users can access them. However, end-users access our reports indirectly and not directly through the JAMS server. We typically share our reports with customers via email, by sending attachments, or by uploading them to SharePoint, OneDrive, or a shared folder. End-users do not directly access our system.

Fortra's JAMS saves us time when troubleshooting. Using the sequence log I have 14,000 jobs running every day.

Fortra's JAMS streamlines our monitoring processes by centralizing scheduling and management, eliminating the need for multiple tools.

Fortra's JAMS freed up the time of our IT staff. Previously, we had 20 servers, each running a different type of application. However, we have now consolidated all of these applications into one system.

Fortra's JAMS saved us the costs of a few full-time employees.

All the features are valuable and we utilize all critical features of the solution, such as scheduling, automation, and notifications.

It is important to receive notifications if a charged job fails and SQL is halted. JAMS does not provide halted notifications by default, which is a critical feature that needs to be added.

Fortra's JAMS has an encryption code, but they are not compliant with the open-source GPG program, which is a requirement. They are planning to add the GPG program by customizing and bundling it with JAMS, which would be great. Currently, we are using open-source software, and it begs the question of why we are using JAMS. JAMS has an encryption code, but it lacks a PGP engine in the server or an extra connection. They have added it, but version 7.3 is not functional. However, version 7.5 offers more job features, increased connections to the store, and enhancements to the cloud base, such as Azure, which makes it easier to access the cloud.

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

Fortra's JAMS stability is great.

Our requirements are met by Fortra's JAMS, and we have not experienced any scalability issues.

The technical support is great. They respond quickly even after hours and are knowledgeable.

Positive

Before we switched to Fortra's JAMS, we utilized a MOVEit SQL Server. However, we found that JAMS is a superior solution.

The initial setup is straightforward. A single server can be set up within a few hours while deploying multiple servers may take a few days to complete.

The implementation was completed in-house.

We have seen a great return on investment with Fortra's JAMS.

There are no additional costs other than the license for Fortra's JAMS which is affordable.

I reviewed several solutions online before going with Fortra's JAMS because of the features and price.

I give Fortra's JAMS a nine out of ten.

There are 50 users in our system, but only my team has administrative privileges. This means that while all users can access the JAMS client and run, release, or cancel their jobs, they cannot delete or modify anything. The remaining 46 users are simply managing their own jobs, whereas my team of four has the ability to modify settings.

I used Fortra's JAMS successfully across a variety of jobs and it is highly recommended. The solution saved me a significant amount of money, time, and effort through effective monitoring and other features. Overall, I believe Fortra's JAMS is a great product that can benefit many people.

I have come to understand the importance of centralizing management within our organization for the benefit of both the company and its employees. This facilitates prompt troubleshooting and efficient communication of notifications.

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