JAMS Reviews

I've used the solution across three employers. I've used it in the context of government, tech services and health care. Everything is IT-related, so everything from ordering supplies to finance applications, everything gets filtered through JAMS. It helps with automation. 

At my previous employer, we were working on a project with the tax controller of our state. And the company I worked for was providing a tax solution for them. Part of that was us being able to provide a solution, but they also had to have their own users be able to interact with the software solution that we provided them. That required them to have their own user accounts and privileges and all that for JAMS, and it was all tied into an SQL database. Instead, if someone joined the controller office or they changed positions or roles, typically, someone would have to go to that SQL database and manually update those records. What I did was I created a series of JAMS jobs that would allow someone just to run a job. It would ask for the basic stuff: their name, their role, and their privilege, and it would update that for them. It made something that was really complicated and annoying super easy.

I really like PowerSchool scripting. It's really easy for me to produce some really cool code. People will ask if a certain job is possible to do with JAMS and I tell them it is. 

The JAMS database offers a lot of flexibility in tapping into it. It's good at offering additional functionality. 

The automation aspect is fundamental to what JAMS is for. If you want to schedule something to run every Monday at 8 AM or whatever, it will work without fail.

The code-driven automation is good for helping us handle complex scheduling requirements. That's a cool thing. JAMS has a lot of flexibility with being able to automate. You can just use the built-in features to run a job. However, you can also just code that into a job using PowerShell. I lean more into writing codes rather than relying on built-in functionality. That is really big for me.

Currently, we use both Windows and Linux servers, and that creates a lot of issues when it comes to talking between two different operating systems. But we're able to get by with that since JAMS has built-in capabilities to call Oracle directly and it can also call SQL. It doesn't really matter what operating system you're running on. 

JAMS is good for helping us be aware and handle common issues that prevent our jobs from running. I have jobs I've built and checked on. I can look at the state of servers to foresee if there are going to be any issues. If we have critical processes that run at 5 AM and the server is offline, then the job will fail. However, we can check-in, or it will give us alerts so that we can see what's going on and fix the issue before the job can fail. 

The solution's ability to handle exceptions that we have created has been sufficient.

JAMS helped eliminate data slack across our applications. We get these reports in, and they need to be run from a Windows server into a Linux server and ingested there. I just created a job this morning that would transfer these files to the Linux server, and then we would run some sort of features that would load them up. It's easy to do that.

The built-in triggers are great. If a file comes in, someone doesn't have to manually look for it. We just have jobs that will scan folders to see if files come in or if they're removed. It makes remedial tasks obsolete as they can just be automated. We've freed up about 20% of staff time as there have been a lot of opportunities to automate manual effort.

JAMS has built-in reporting. I've never really used it. I tried using it a few years ago and I couldn't figure it out. It was wonky. It could be improved upon.

There's a projected schedule pipeline that's never really worked for me. They could fix that and make it more user-friendly. 

I've used the solution for about nine years overall. 

It's an absolutely stable product. While I don't mean to sound negative about the web version, I will say the desktop client version has been rock solid. I'd rate stability seven out of ten since the web version skews a bit slow. If we were just talking about the desktop version, I'd rate the stability ten out of ten. 

The scalability is good. I'd rate it nine out of ten.

About 20 people use the product in my current organization.

JAMS support is fantastic. I've been bothering them for years, and they always get back to me right away. They're amazing.

There was a different solution in place that the company chose not to use. My current company migrated all of the jobs over to JAMS.

The initial setup is straightforward. We did a migration and were able to set it up in one to two hours and five people were involved. The migration itself was finished within a month's time. The main issue was handling the volume of everything they had to migrate.

There isn't really any maintenance needed. There are just some backend things, like whenever a job runs, it creates a log file, and those need to be cleaned up. Otherwise, they begin to build up. Then, every once in a while, you may have to do an update. That's about it. 

Resource-wise, we've definitely witnessed an ROI. 

The pricing is completely reasonable. 

The solution has positively impacted productivity. The ability to able to automate manual tasks and being able to check on file transfers, et cetera, has been great. It helps tremendously.

Right now, we're using version 6 of the solution; however, we're actively talking about getting version 7 this summer. 

I'd rate the solution ten out of ten. 

We run application software for auto finance companies, banks, and the auto company's financial departments. We use JAMS to schedule all the nightly and repetitive batch processing. We run around 10,000 jobs per day.

We've had batch schedulers before. We’ve had CA7 on the mainframe. Our on-premise data center had another product. They were a little more cryptic and not as intuitive to look at. We couldn’t figure out what to do. In JAMS, we can figure out whatever we need to do pretty easily. It has a really good user interface and straightforward scheduling functionality.

JAMS is easy to use. We came up with various scenarios for scheduling. With a little bit of thought, we figured it out and implemented it pretty simply. Calendars, building new jobs, and crisscrossing dependencies are easy to update. If something fails, we can rerun it or skip it with just a couple of mouse clicks. The information displayed on the monitor is very informative. I have a team of 24/7 operators. The team members watch it run and make sure everything's on time. If anything fails, they address it. The product is pretty good for them. It’s pretty easy. I like the solution overall.

The product does not allow the users to cut and paste the job names from the screen.

I have been using the solution for three to four years.

I haven’t experienced any stability issues in the solution.

We're running ten thousand jobs and haven't had any capacity issues. We don’t have it on the busiest server. I'm sure we could run it on a larger server, and it would get even faster. However, it seems to be doing well, and we keep adding to it every day. The operations staff are the users.

I had an amazing experience with the technical support team. The team members respond right away. They answer the phone usually without going into a queue. Their support is amazing. That is one of the key reasons why we selected JAMS.

Positive

We were using AutoSys on-premise. We didn't really do a full POC. Once we had the demos and compared the features, we decided to go with JAMS. Since it was the first thing we were doing in the cloud, the testing was like a POC. The whole environment was brand new.

The migration wasn’t difficult. We have documentation on all our jobs. It was just a matter of building them out. Once we finish a few jobs, we can clone what we've done and make minor tweaks for the next one. It's pretty easy.

It took us a little less than three months to choose the product and start using it. There was a lot of discussion about how to build the firewalls between servers and get access to the servers that we would put the agents on. All of that was new to us. It took us a little bit longer than someone who already has that established and is just swapping one tool for the other.

Everything is in the Azure cloud. We have three instances. One instance is for DR, one for prod, and one for non-prod. Lewis Diaz helped us get going when we first went live, did training, and helped us talk about how we had it built. From there on out, we've been self-sufficient.

We had all our clients in an on-premise data center in Atlanta, and we started with our first client in the Azure cloud. We built them out, and they went live in April 2020. Little by little, we kept bringing clients from on-premise to the cloud. We were ready to go in less than three months. It probably could have been done sooner, but the migration and coordination with our clients took a lot of time.

One of the support persons from JAMS had come to our organization. He gave us a three-day training and reviewed what we had built. He gave us suggestions on how to do things better. We have one main person who is an administrator. Another person and I are a backup to the administrator. I am a manager. It doesn’t take a lot of people to maintain the product.

The product is giving us a lot of value for the money we're paying.

For what it does, the product is priced very well.

We evaluated AutoSys, but we weren't thrilled with it. However, we included it in the comparison to consider the pros and cons. Security was a key concern.

JAMS servers run our main software, and agents are installed on separate servers where our code runs. The license came with five agents out of the box when we bought the license. It was plenty. We're balancing our load across three servers right now. We had another office in Buffalo with just a handful of jobs we set up. It will run there until we can get those into the cloud, too. We're not even using all five.

It's pretty easy to set up a new agent. Most of the workaround is related to firewalls, getting access, and security. Once it's up, we can run things in that environment. We watch for capacity on the servers that we have the agents on. We're running a ton of stuff currently, but we haven't had any real issues where servers hit high CPU or memory. Performance has been good. We use JAMS only for traditional batch-type operations.

We have alerts for long-running jobs and jobs that could not even start. It's error handling. It has different levels of errors, like informational errors and critical errors. We can mix and match and set up emails to be sent to our team according to the alerts. The tool's alerting capability is pretty good.

The solution has an alerting feature to let us know about exceptions. We've even been able to set up what actions it has to take in different scenarios. It's great.

We're using the product to centralize the management of jobs on all our platforms and applications. We're about ninety percent there. It is important to our organization, especially from an employee standpoint. We need one tool that everybody can be trained on and know about. Having multiple tools across different platforms and having people learn more than one thing is troublesome.

In some of the really difficult situations regarding scheduling and everything, we were able to put something in and get it to work with just a little thought. We did not have to spend too much time on it. It was pretty easy. I like the integration with PowerShell. We use PowerShell a lot. If we're supposed to get ten transactions a day, and we only got five, we run a PowerShell job that checks that count once an hour. If the hourly count is under five, then we fail the job. We use it a lot for monitoring our applications.

We have tons of file transmissions, but we use a different product. JAMS has a really good file watch feature that we utilize all the time. The job runs as soon as the file arrives and does whatever it needs to do with the data. Then, it's available for the business to do what it needs to do.

JAMS helps save time when troubleshooting stalled jobs. The job log is easy to access. We can get that to our programmers if needed. There are many screens showing the job name, but we can't cut and paste it. I'd love to be able to cut and paste the job name from anywhere it shows. It will help us send it to our developers without going elsewhere to find or type it out.

We upgrade every two years to the current version. It's a lot of effort for us to upgrade our products or tools. That's why we're on a two-year rotation unless a major security update would come out. Then, we'd have to upgrade right away.

The product hasn't eliminated the monitoring tools but has augmented them. We only use Azure Monitor. We don't spend a lot of money on monitoring tools. Azure Monitor is included with our Microsoft Azure license. Most of our stuff is set up around that. Our jobs are set up in JAMS. It scans the Azure logs for certain buzzwords. It's all mandated. It's never going to make it go away.

Everything we run in prod, we run in non-prod ten times more because we have ten test environments. We've always had that with whatever product we had. It does help. The developers don't have to manually run a thousand test jobs in a release. However, we always had that configured no matter what product we had.

People looking to buy the solution must get somebody to come out and do the demo. Everybody is very knowledgeable and very professional. They know their product. They're definitely great ambassadors. They put on a good show, and then they stick to it. They back it up with reality.

Overall, I rate the tool a ten out of ten.

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.

Most of our use cases are for automating our SQL jobs to run and send an email.

It used to be really hard for us to set up SQL jobs to email, once they were done. Or, if there was a problem, we couldn't get it to do anything smart and intuitive because that's not the way SQL works. Once JAMS came along, we could set our SQL jobs to run at 1 PM every day. When a job runs, if it can't get its data or it takes too long — or whatever criteria we set up for it — it will email us and let us know that the job needs attention.

That really has helped. When I first started here 15 years ago, I ended up having to babysit SQL jobs all day long and watching for code that wasn't written correctly, or for a lock on something that stopped the job, or somebody didn't put timeouts on it. Once JAMS came along, we set up one set of criteria for quite a few jobs, and for every job we could say, "Here's your database, and run it with these criteria." That freed up our developers' time and my time, and we had a trackable source that would tell us what was wrong. It literally changed all of our lives.

I no longer have to wait for someone to give me all the information about a job that failed, wait for somebody to respond, or question somebody about what they're asking me to fix. It's all right there. The dashboard for JAMS is very intuitive and informative.

It's helped save time—in the extreme—when troubleshooting. Our jobs don't necessarily stall anymore because we've fixed everything that ever stalled. We now know how much of a timeout to put on certain data sources or certain procedures, but we would not have known that as easily without JAMS.

When we first began using JAMS, it freed up about 50 percent of my time, or 20 hours a week. And it saved each developer about 10 hours a week, and maybe more. There have also been some advances made in SQL that have helped. But because we've been using JAMS for so long, the savings are really immeasurable. We've relied on it for so long, and we'll continue to rely on it in the future.

When a job doesn't work, all I have to do is open JAMS and open the job and, 99 percent of the time, it tells me what I need to do, or what happened, or I know where to look. Before, if a job failed and just kept failing, we had no idea where to even start looking. We'd have to go to the logs on SQL Server, which meant everybody had to have admin rights to look at the logs. Now, we have just set up JAMS to run with a service account that has the ability to do that, and then everybody can look at their own jobs and fix them. Sometimes, it's just a matter of needing to rerun a job because something was down in the network.

By setting it up with a service account that has access to everything, we don't have to run it under my name or anyone else's name. We can set it up so that everybody has permission and I don't have to worry about granting someone permission. And I don't have to give them access to the email account where the failure or success email might be sent. Everything is done with the agent or the service account. And when a new data source comes online, we just give it to the service account agent, and that sets it up so that everybody has access.

Another way it has helped is that before a client logs in to see their daily reports, and they're not there because something happened to them, we're saved by the fact that JAMS emails tell us that it's happened. We can go in and fix it before the client logs in and finds out that something failed. Or, if something was down, like FTP, we can let the client know in advance so that if they log in, they will know that the data is not available and that we know already and are working on it. JAMS has made us look smarter to our clients.

For example, when you log in to your computer and do a local Google search for shopping, the results that you get can cost our client a lot of money. It is very hard to get the top result without spending a lot of money because what Google says is that your data integrity matters a lot. If your data is stale, or you haven't done a refresh on your inventory, Google will push you down in the results and move somebody else up. That means that stale data is a big concern for our clients. Some of our clients rely on Google for 90 percent of their business. If we have their data messed up, their business is messed up because of us. We have to know that their jobs are failing and why, and be able to tell the client, early on, that this is happening so that they can do some manual uploading until we fix what's wrong.

The scheduler is the most valuable feature. Using that, we can set up all of our data sources to be available. We use multiple different data source providers and they're already in JAMS. All somebody has to do is go into JAMS and say, "I want to use Adverity," or, for whatever client it is, that they want that client's data for these dates and these criteria. They can specify that they want it sent to this database or that FTP, and with only these column names. Whatever we want to do, we can almost write the code to do it in JAMS because we already have so much data in there. It's as if JAMS has made itself into its own picker.

It can also do exceptions, you just have to remember to program them in. As a rule, when you first start out with a job and JAMS, you probably aren't going to tell it what to do with errors until you see a pattern in your errors. And then you can say, "Try three times but wait five minutes each time." You go into the job in the monitor and it says it failed. Then you can change the criteria, such as how long it's holding, or repeat the job every 10 minutes until successful.

The code-driven automation for more complex scheduling requirements frees up time because it's really easy to use. It looks complicated, and when people start using it, it might seem a little bit overwhelming, but after you get all the definitions set up, it is very easy to do. It's almost like a stand-alone software that we can't live without.

JAMS is going to disagree with me about the following, because they think that this is not always a problem. But since COVID, we have had a lot of people working from home who can't always connect to the JAMS server. We use VPN, as most companies do, and we have it set up so that everybody can access the JAMS server. But many times, our people cannot access it.  They'll try to log in to JAMS and will tell me they can't and I don't know why not. Nothing has changed. 

I have to look at their access and what is wrong with their IP. We've discovered some problems over the years that have been the cause, and that's because it's all behind the scenes to us. We have two VPN servers and we figured out that one of the VPN servers didn't have the permissions for it to log in to the JAMS IP address. We fixed that. And sometimes, new people think that they can just log in to the JAMS server, but they haven't been set up with permissions. 

But JAMS could do a better job of telling you what the problem is when you try to log in to the server. The way it works now is that if you can't log in to the server, it brings up a long form that you have to submit. And nobody likes to submit a long form and sit back and wait.

We've been using Fortra's JAMS for at least eight years.

JAMS is scalable but the problem that our company has is that we have about 144 companies under one banner. For example, if we have an airline company under our banner, and another company has an airline under their banner, we can't be connected because that would be a breach of contract.

That means we can't share our JAMS server with another company under our banner. That's a limitation of the JAMS license because you can only use JAMS on one server at a time; one license, one server, that's it.

Given that we're paying all that money, it would be nice if we could have it installed on a couple of servers so that one airline and another airline could both use it but not be on the same system.

JAMS support is very responsive and they know who I am when I call, so I don't have to go through their making sure that I'm an authorized user, et cetera. 

JAMS has versions and they only work with certain other versions. For example, if JAMS 21 is the current version and I'm setting up somebody in it, but they're connecting to our on-prem server, they have to have JAMS 6 instead of JAMS 7. If I put them on the wrong one, they'll never be able to connect. So when I have to re-download an older version of the software if I don't have it saved, JAMS always reaches out to me and says, "Do you just need software or something else?" They take a proactive approach to their support, which I appreciate because sometimes, when they contact me because I have to do a download, I'll say, "Hey, I have a quick question," and I can throw that in without waiting for a couple of days.

They're really the closest thing that we have ever found to being like a coworker who is dedicated to doing nothing other than fixing and scheduling things and checking on all of our data.

Positive

We never had any monitoring tools, other than the fact that we could look at the SQL logs, but that's like reading a foreign language. Rarely does the log ever lead you to an actual solution to a problem, whereas the JAMS logs do. They tell you what happened and to look at this or look at that. Sometimes it will even let you know that a password has expired, for example. At times, it tells you everything you need to know. At other times, it gives you enough that you know where to look and you can see that the login is not working, or the source is down, or for some reason, there's no data there for the day.

Things have probably changed, but back then, if you had SQL 2016 and 2018 and you set up a scheduled job for data in 2016, some of it was bound to fail. With JAMS, we don't have to worry about that because it will automatically tell us what version it is, and even tell us it won't work so we can easily fix it.

The initial setup was very straightforward. I can also export from my on-premises JAMS and import them so that the jobs and all the data criteria do not have to be set up on a new server from scratch. That is very helpful and that's what we did when we put it on the Azure server recently. 

For that project, we initially set aside three days where four of us were going to work on it because it took years to get JAMS exactly how we wanted it and we thought it was going to take a while. But it was very simple. It was up in about two hours.

A lot of people in our organization use JAMS with the service account. But in terms of people who set up new jobs, we have six admin users. There are another ten or so who use just the service account.

When we first got the software, we had something like two half days with JAMS people over a screen share. We've always had a service contract with them and the couple of times we've ever had to reach out to them they were very responsive. When we set this up, on our Azure server. We did not have to reach out to them.

We have absolutely seen return on investment with JAMS. It comes down to the fact that our developers can actually spend time developing instead of troubleshooting and looking at why SQL or the data source isn't working. Or they can simply say, "Hey, I got this email from JAMS, Kammy can you look at it?" Or they can say to my boss, "We have to stop using this data because every day we're having problems getting into it. Can we have a meeting about this?" All of that is JAMS-driven.

In the end, you'll find that it's really worth the price. There is some sticker shock, but it's worth every dime.

Several of us evaluated other options, but JAMS was what we all came back to because it was the only software we found that could do everything that we needed it to do for all the different kinds of data that we get. We deal with over 90 data sources with different kinds of data from different kinds of companies, and JAMS was the only one we found that really could handle them all.

JAMS doesn't centralize the management of jobs for all of our platforms because we have things that aren't built on SQL databases. We can't automate the login to some of the data that we work with because other places don't allow it. We would have to do that interactively with JAMS, so it would almost be pointless to use JAMS for something like that. But JAMS centralizes most of it. If you look at our scheduler compared to how many people used to have to run jobs manually every single day, or had to remember to do something and go back and look and see if it was successful, every single day, the difference that JAMS has made is tremendous. That is why JAMS is worth every bit of its very expensive cost.

My advice would be to understand that if you're spending hours a day or a week trying to figure out why

• SQL or automated data jobs or
• logging in manually and downloading data and moving data around or
• even archiving data (we do a lot of data archiving through JAMS because we can tell it: "if older than X, delete it.")

isn't working, JAMS can handle it all.

For anything that you code manually or have to pull up a script in SQL and look at logs for, JAMS can make it all easier, so that you don't have to do those things every minute of every day. You can spend about 10 minutes a day on them, whereas you might have spent three or four hours before.

We have many uses for JAMS, primarily for jobs in our data warehouse, but also jobs for debt integration, ETL, moving data between organizations, scheduled archives and database maintenance, data quality work, and triggering analytics model updates.

We used to have a job scheduled to start at 03:00 AM, and it would run to 10:00 or 11:00 AM because we had to add enough buffer time between jobs to account for time variability in individual tasks. This often caused problems in production because the database would still be in use when our staff came in the morning, leading to user reports of sluggishness in the database. With JAMS, this process is completed by 06:30 or 07:00 AM, long before our users get in, so they're happy, and I'm happy. Everything is done by the time I get in to work, and I just have to take care of exceptions if there are any. JAMS is a win for our organization.

JAMS helps to centralize the management of jobs on all our platforms and applications; I transitioned everything over to it so we have a single application to control all tasks, which has been tremendously helpful.  

JAMS helped eliminate ''data slack'' across our applications, ensuring that current data is ready when users need it. Referring back to my previous example, the data warehouse job took until 10:00 to 11:00 AM to be completed, and users had to wait until then for full reports. Now, that's all done before they get into the office.   

The product helped to free up the IT staff's time, especially mine as the primary administrator. It saves me at least two to three hours a week on average.  

The product reduced the time it takes to carry out data warehouse jobs and send out reports by half. 

The ability to sequence jobs is excellent; it means we don't have to schedule them individually, and if one fails, it doesn't unwind the entire workflow.

JAMS is excellent for helping us be aware of and handle common issues that can prevent jobs from running. The solution notifies us when jobs go sideways, which is extremely helpful. Additionally, we can change our parameters if the network changes or if adjustments are made, allowing us to quickly alter a bunch of jobs just by updating a parameter. 

We use the solution's Interactive Agents; we deploy them on different servers to run the jobs directly. Adding interactive processes is very important to our organization.   

Running interactive tasks helps users focus on business processes. I'm the primary administrator for JAMS. It helps tremendously by allowing me to offload all the problems that can occur with jobs and all the associated rescheduling and rerunning of them. With JAMS, my job is much easier.  

JAMS is second to none when it comes to handling exceptions, exceptions meaning issues where a job might fail for one reason or another. I can dive into the job, and the log files are centrally located so that I can find the root cause very quickly. I can then address the issue, fix it, and rerun it all from one application.  

The platform's code-driven automation is excellent for helping us handle complex scheduling requirements. There hasn't been anything we haven't been able to do through PowerShell. 

JAMS helps us troubleshoot stalled jobs; it points us in the right direction as the centrally located log files allow us to see how far the job progressed and the specific point of failure. It gives us a good starting point for troubleshooting.  

Fortra is getting much better with documentation and examples, but there is still room for improvement.

There are a few minor issues on the schedule for items to be fixed; there are workarounds, but I'm looking forward to a patch that will resolve them more conclusively. There's a built-in report executer to deliver reports, which we can send to an individual, but we can't CC other staff, for example.

We've been using the solution for a little over three years. 

The solution is exceptionally stable; I can't think of a time when we had any issues.

The solution is scalable, as far as I can tell. We don't do rocket surgery here, so we haven't had to scale, but we could if needed. We have three users in total; two regular and one occasional. 

The JAMS customer service and support staff are unmatched in their ability to assist us and help us resolve issues. I rate them ten out of ten. 

Positive

We previously used Windows Scheduler and SQL Server Agent, so these aren't really third-party products or competitors to JAMS as such.  

We didn't migrate from a third-party product but switched from using a SQL agent built into SQL servers. Those jobs are triggered by JAMS now. We did a POC before migrating, and it took about two weeks. 

The migration process was as easy as it could be. Migrations are never easy, but it was as easy as possible.  

I was involved in the solution's deployment, and it was straightforward; it took less than a day. We didn't have much of an implementation strategy as we're a small shop. Usually, one other employee and I work with setting up servers and installation. He did the server setup, and then we configured the product, making minor tweaks as needed.

We did not use a consultant, though we contacted support for some advice, and they were extremely helpful.

In time, we have seen an ROI with JAMS, and the ease of use is a significant factor here. I reflect on how much time it has saved me, two to three hours a week, but it likely saves much more time in terms of setting up jobs and so on. On top of that, the visibility into where jobs fail, and the ability to fix issues as a result, makes our entire process more robust.

The product is reasonably priced, and we don't have any add-ons.

We did a POC with ActiveBatch Workload Automation, but JAMS is the more modern tool, the price is much better, and the ability to script using PowerShell is a big plus.

I rate the solution nine out of ten. 

My advice to others considering the solution is that they will be surprised by how much it will help.

JAMS did not help eliminate any monitoring tools because we had none.

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

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.

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.

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.