Fortra's JAMS Reviews

We use Fortra's JAMS for scheduled tasks. We have over 100 virtual servers, and JAMS allows us to manage scheduled tasks from a single location. This means that we can create jobs and run them on any of those 100 servers. For example, we can create one job to reboot a specific server at a specific time, or we can create a job to reboot multiple servers at the same time. Once the reboot is complete, we can create chain jobs to kick off other steps, such as running a script or sending an email notification.

We have not had many problems with Fortra's JAMS. I think most of the issues have been due to trial and error. A lot of it depends on us, the users, to make sure our code is correct when we create commands. We need to make sure that all of the information is accurate. We have to double- and triple-check our code to ensure there are no issues that will prevent jobs from running.

Fortra's JAMS helps make our lives easier by allowing us to automate tasks.

Fortra's JAMS helps us centralize the management of all our platforms and applications. This is important because it allows us to manage all of our systems from a single location. Previously, we had over 100 virtual servers, each with its own set of scheduled tasks. This meant that we had to log in to each server individually to view and manage the tasks. With JAMS, we can simply open the client and view all of our jobs in one place. This saves us a lot of time and effort.

JAMS' code-driven automation is highly effective in handling more complex scheduling environments.

JAMS saves us an hour of time when troubleshooting stalled jobs. 

JAMS helps to free up our IT staff's time.

Being able to create a series of chained jobs, which are basically linked jobs is valuable. This means that we can schedule a server restart at 2 a.m. Once the restart is complete, we can have the job trigger another job that will send us an email notification. Then, we can have that job trigger another job that runs some SQL statements or Power BI queries. We can continue to chain jobs together in this way.

As an admin, I would like to have a web-based GUI instead of a client application that we have to install on our PCs. Many applications are moving to web-based GUIs, so it would be convenient if we could use JAMS without having to install a client on our machines. We could simply go to our local servers or website and manage everything from there.

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

We have not had any problems with JAMS. It has never crashed for us. If we have any issues, it is because of some of our PowerShell code or another error.

JAMS is highly scalable and could be used for a lot more than what we are currently using it for. We just haven't had the time to invest in it to actually use it properly.

The technical support has been excellent. They have always responded promptly and in a timely manner. We have never had to wait for answers.

Positive

We previously used the built-in Windows task scheduler before migrating the jobs into JAMS.

The initial setup was really straightforward and easy. I didn't run into any problems from a setup point of view. 

One person was required for the deployment.

We completed the implementation ourselves in-house with some clarification about some settings from JAMS.

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

The pricing of JAMS has not been an issue for us, as it has allowed us to save time. This makes it a cost-effective product.

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

Five people are using JAMS in our organization.

Fortra's JAMS is a great cost-effective solution for automating daily tasks, such as rebooting a server, running PowerShell commands, executing SQL queries, and generating SQL statements. It can do virtually anything.

It has set times for set jobs that have to run, jobs that previously would have been done by someone manually. JAMS covers that now. But it also helps afterward. If I have to run something on four or five servers at a set time every day, I would have to make it run, check a log file on that server, and flip about between all the servers. Now that I have it in a central location, that is much easier.

For my job, in operations, and for IT, it has definitely helped to centralize the management of jobs on all our platforms and applications. If it didn't do that, we wouldn't use it. When our contract with a competitor was up, we looked at other companies, like VisualCron, that were cheaper, but one of the main sticking points was the fact that they wouldn't have provided a central location for us to monitor across all servers. That was one of the biggest selling points of JAMS.

It enables us to scale quicker, and it has saved countless hours of manpower. I can actually fire-and-forget some of the stuff now. I know that JAMS is going to tell me if some of the basic tasks haven't succeeded. I can do more things with my day. It handles about 1,000 processes for us a day, processes that would require something else, and about half of them that would require a user or person on our side to do something.

It has helped to free up IT staff time in every way. If I had to do all the things that JAMS does for us, I might not get to do anything else. Four to five hours of an eight-hour shift are probably saved by having JAMS do things for me. Everything that JAMS does is what our entire team would do for the day. But because we don't have to do that, we're free to work on other tasks not related to operations, such as customer issues or our ticketing system. If we didn't have JAMS we would put something else in. There would be no way we could do everything without JAMS. Or we would do it, but it would be a nightmare. At least fifty percent of our overall staff's time, of seven people's eight-hour shifts, is saved.

JAMS is also giving us more access to data that was there. It has improved our ability to process and ingest it. We're a financial company and we run on schedules and set times and changes to data are important.

Another factor is that it certainly helps save time when troubleshooting stalled jobs. The fact that it will give you the log as it is written, rather than having to wait for something to finish, is helpful. At least you can see how far along the process or application has gotten and that gives us a place to go when troubleshooting. We have the ability to start and stop something if we need to.

The amount of time it saves us would depend on what has failed. We don't have a lot of failures because we can't afford to have failures. But it could save us about ten minutes on a job in investigating what step it failed at. When a process is running, if we know exactly where it failed, it means we don't have to go into a database or go look at logs to figure out how far along we are. Or if a job had to write 20 pages and we look at the JAMS log and it shows it has only written 10, we know where to go look. Whereas if it just said "stalled", we wouldn't know where it stalled.

Also, we had our own bespoke file-watch system, but the JAMS file-watch is so reliable that we use it for monitoring that sort of thing. It has removed personal monitoring of jobs and having to go in and look for things, but we needed to create JAMS into a separate monitoring system. It has definitely helped.

Some of the valuable features for us are the

• automation
• scheduling of tasks
• file watching
• dependability.

It's basically a super version of Windows Task Scheduler.

Adding Interactive Agents is extremely important to us. Running interactive tasks gives us a central location for multiple processes across multiple servers. If we didn't have JAMS, and we were using just a standard Windows Task Scheduler, we would need some way to log in to multiple servers at the same time, look at jobs and check if one had finished and then kick off another one. You can do all of that by just following one item in JAMS. You can set sequences with a dependency on one thing finishing before something else will start.

It's very good at bridging the gap between structured batch automation and processes happening on desktops. That's really what we do with it. It does its job and it does it very well.

I also like the way it handles exceptions. It can handle its own exceptions, but we can also configure it to handle exceptions from our bespoke applications. If there's a certain return code, we can get bespoke errors. That means it can either give you a JAMS error saying, "Something happened within this job", or it can give you, as the error, what happened within your application. That's very important to us because we hook it up to a different system and what comes out of JAMS goes into a different system separately. It works.

The documentation is not super. There are things that I want to do in JAMS, but I just haven't gotten my head around them yet. For example, I keep saying that workflows would be really handy for us. We can't risk moving our production stuff or testing stuff there. But when I'm testing in the UAT environment, I run out of jobs. They have examples that don't apply to my situation when it comes to running things. The documentation is probably all there, but it's not the easiest to navigate through. It's not as quick and slick as I'd like it to be.

Their support team is a live chat and they are top-notch. I can say I have a job that's failed because of something, and they can probably give me a pointer, really fast, on what's happened, but I wouldn't use them if I'm trying to learn a new functionality or process. I wouldn't ask them to give me a complete step-by-step. That's not their function. They would probably point me to some documentation that would be a massive PDF or some support page, but I just lose the will to live reading them.

I've been using Fortra's JAMS for two or three years.

The stability is fine. I have had no problems with it. It's one of those things that has never gone wrong for me.

It's very scalable. You would only be restricted by the number of jobs that you are licensed for. You can buy a license for, say, 10 jobs and scale to 10 jobs. You could buy a license for 2,000 jobs and scale to that. The costs go up massively, though. The ideal would be to have unlimited jobs; that would be amazing. Technically, JAMS can be as scalable as your infrastructure will allow, but it's probably not as scalable due to what your wallet will allow.

Their technical support is excellent. They're a straight-up 10 out of 10; really good. I've only ever contacted them via email and live chat. Once, when I couldn't get through on the live chat, the guy made a Teams meeting with me, we shared screens, and he went through it, because there was some strange error I was getting. 

Those guys are brilliant. And if you don't get them on live chat, someone picks you up on an email very fast. I can't say enough good things about JAMS for support.

I wouldn't bother them with questions about how I should do something. I would only use them when I have set up something and it's not running as I think it should and I don't know how to make sense of it. But if I've done, say, 80 percent of the work and it's still not working, they will say, "Oh, well, you've missed these four configurations."

Positive

JAMS has made us more productive. We didn't have to hire someone new to do some of the stuff we wanted to do because we could pawn off some of the work on JAMS.

Once you get all the basic server permissions in place, the setup is easy. It pretty much does it itself. You install the main client and a few files. You configured it a bit, and then installing the agents is easy. It's more about the infrastructure you have set up. That is where your main issue will be.

It's on-premises. We deploy a central client on a server, and there are agents that go onto production servers, like an application server, a database server, or a web server. You can set all your jobs from the central location and it will run them on the actual production server. Take, for example, a PowerShell script. You put all of that into the main client and it just runs that wherever you're asking it to. That's what the agents are.

From "blank" to actually getting JAMS working took half an hour. But it depends on how far you're going with it. If I wanted to just get the JAMS client and one agent set up, that would take half an hour. But we have loads of servers and we're constantly adding to it. Per agent, it takes about 10 to 15 minutes.

We didn't migrate to JAMS from something else. You configure all the jobs, but you wouldn't want JAMS to help you with that because they're your jobs. You're telling it what to do. We went from manual tasks. It all depends on the size of your deployment and how much you want JAMS to do, as well as on the complexity of your jobs. Some of your jobs could be one-liners and some of them could be multiple steps and they can go up to massive complexity.

We did it in-house. We knew what we wanted to do with it. Most of our stuff is command or PowerShell, SSIS, and SQL. And if anything goes wrong when trying to set up a job, we talk to their support team, but we're fairly handy with what we are doing.

Installing the actual application took two or three people, and included someone setting up permissions and someone configuring things. But in terms of setting up how our JAMS works compared to a blank JAMS, everybody gets involved.

I'm sure we have had ROI in terms of how productive we are and what our output is, but I wouldn't be able to quantify it.

Definitely check how many single processes you want to run and count them as jobs. That is how you would work out your pricing on JAMS. For example, if you're running a number of commands and you can put them all into one script and run that script, you can count that as one job. That job count is where you're limited, per day. 

You purchase a number of jobs in your license. You can be clever with that by combining things into one job. If you can configure it right, you can get around those limits and save some money.

There are loads of other applications that do similar things, like Octopus Deploy, but they are for installers.

Our shortlist came down to VisualCron, which we tested as well, and JAMS. The reason we went with JAMS was that if I have JAMS open, I'm probably on a page called monitor. That is the list of upcoming jobs that it's about to run or jobs that are executing. After a job has run, it will sit there for about ten minutes and then it will go to a historical page. That monitor page is vital because it shows us what's coming up and how something is executing as it's happening. It gives you a log of updates and you don't have to wait for that until it has finished the job. You can see the log in progress.

The benefit of VisualCron was that it gave us an unlimited number of jobs, but an updated scheduling page like that literally wasn't feasible.

We didn't test the other solutions we looked at mainly because of cost. Our main requirements were cost and the number of processes we could run a day.

If you're looking at JAMS, you probably know what you're looking for. It's a scheduling tool that probably integrates with whatever you're already doing. It takes the manual stuff out and it can connect to just about everything Windows already, including SQL Server, PowerShell, and the command line.

If you have a lot of manual tasks that you run, JAMS can probably run them for you. You'll want something reliable like JAMS.

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

It's deployed on AWS.

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

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

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

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

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

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

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

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

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

Positive

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

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

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

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

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

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

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 have batch processes that run either on-demand or on a scheduled basis. JAMS is used to manage and run those jobs.

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

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

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

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

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

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

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

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

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

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

It's also a scalable solution.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We have been a JAMS user since late 2013.

It has been incredibly stable over the last nine years. 

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

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

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

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

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

Positive

It didn't really replace anything.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We use it to schedule batch jobs. Batch jobs are a combination of SSIS jobs, which is actually our group's main use case. I brought it in mostly to schedule our SSIS batch jobs. Then, there are other groups who are using it for SQL Server stored procedures. We also have another group using it for a few Python scripts and FME, which is a different type of ETL tool. So, we are using JAMS to schedule those four types of jobs as well as a bunch of FTP jobs.

The application developers have been doing a combination of migrating some of their older jobs, like Python scripts and SQL stored procedures, and FME jobs over to JAMS. Any new batch jobs that they are creating default to using JAMS. They mostly do interactive online type applications. However, on occasions where they do need batch processes, they just use JAMS.

The fact that we no longer need to use Excel spreadsheets is huge. Before JAMS, every group was keeping track of their own batch jobs. Nobody really knew what the other jobs were. So, if jobs failed, other groups wouldn't necessarily know. With JAMS, everything is done through a single scheduler. You can choose who to notify. 

The ability to work out dependencies between jobs is the most valuable feature, which is actually the main reason why we went with JAMS. We went from everybody trying to keep track of stuff on Excel spreadsheets to being able to see things graphically, and say, "This job should not continue or start unless another job begins." That is very useful. Plus, we have a bunch of jobs that are using File Watchers. So, the job doesn't start up until a file is put on a shared drive, which is the automation that JAMS provides that the old SQL Server agent did not do at all.

It provides notifications. 

The fact that JAMS provides metrics is actually nice, although this feature is not really used that much. Before it was a lot harder to get metrics, whereas there are now metrics if we want them.

The client needs a complete revamp as it is not the most intuitive of methods of setting up jobs.    We have encountered situations like options disappearing and with no obvious way of getting it back, we have had to open up a Support ticket just to figure out how to get the missing options back

I have been using it for around three years.

We are about two versions behind. Our upgrades are done by our infrastructure team. We decided that to reduce the amount of work for them that we were going to limit upgrades to approximately every six months, because JAMS does frequently update their software. For the most part, it is fairly stable. We have basically worked out with our infrastructure team to not update every time a new version is released. So, it is done around twice a year.

The product is quite stable and we haven't run into any major issues.

Our infrastructure is pretty straightforward. It is just SQL Server jobs. It works fine on all our Windows machines. We might be exploring a Linux machine for scheduling a SQL Database job, but we haven't done that yet. 

The plan is to have all our batch jobs managed by JAMS. For various reasons, mostly related to strange quirks, they weren't able to just migrate every single thing to JAMS, but that is the end goal. We want to have a single scheduling tool that manages all our batch jobs.

We haven't really encountered any scalability issues. Most of our jobs run at night. We have a bunch of daily jobs that run every half an hour. Therefore, it has not been a huge strain on the JAM server.

There are not that many users of JAMS, probably five or six. We have one administrator who is part of our infrastructure team who can configure JAMS etc., but acts in more of an implementer role. He was the one who installed the software. Setting up jobs and things like that is left up to my group. There are two people in my group who have permission to create and submit jobs. Then, we have about three or four inquirers who look at the output of the jobs, but don't have the permissions to submit jobs.

Reach out to their support, because they're support is really good.

I would give HelpSystems IT support a nine out of 10, which is really good. I have been very impressed with their support. The only reason for a nine out of 10 is sometimes it takes at least a day for them to get back to me, which isn't really that big a deal. However, for the most part, if we do it within U.S.A. working hours, then I get a response pretty quickly. Also, after hours, I think I have sometimes gotten their London support.

We have had situations where we would hide things and could never figure out how to actually get things back. We would inadvertently just hide things without even knowing that we hid them, then we literally have to reach out to JAMS support. As far as kudos, JAMS support is excellent. They are very responsive. There have been little things like, "We lost a window. How do we get that back?" The fact that you had to hover over a specific area of the UI, then depending on where you hovered, you could get that particular window pane back. That was the first thing that we ran into, because it was like, "We lost this. How do we get this back?" 

I actually was the one who brought the product in. My group was looking for a scheduling tool. Until I arrived, everybody was just using the built-in scheduler, which was fine, but it was impossible to look at things practically or even determine dependencies. So, everybody was just using spreadsheets, but I hadn't. The place I came from, which was the private sector, had money. They were using a full-fledged scheduling software, Control-M, which was really expensive. When I came to San Francisco Public Works, they didn't have it. Therefore, I started looking around to see what was available. 

Previously, we were using SQL Server Agent. Migrating these has been going well. One of the great advantages of JAMS is it can just convert SQL Server Agent jobs directly, which is not ideal because you are still running SQL Server Agent. This is one reason why we are doing things slowly. We are decomposing the SQL Server Agent jobs into steps and scheduling those, rather than running SQL Server Agent jobs.

The initial setup was pretty straightforward. We just followed the instructions that were on the webpage. So, on the actual JAMS site, there are steps you need to follow if you are installing JAMS. We just followed them and pretty much everything worked. 

The deployment took less than an hour. It was pretty quick.

We went from nothing. We just deployed all the new tasks first. So, all of the SSIS jobs that my group had built. These were all new. We didn't really have anything to convert because it was already there. That was the initial phase. That is why it was pretty quick. Once we were comfortable using it, we started to expand the use of JAMS to start converting some of the SQL Server agent jobs into JAMS.

We migrated from an on-prem JAMS to an Azure VM JAMS. So, we actually did a migration, which also involved an upgrade in the process. There was a time when we hadn't upgraded JAMS for over a year, so we were way behind. What we were told by JAMS support is to upgrade our JAMS first, then redeploy it on an Azure VM, and that went without a hitch. I was quite surprised and impressed by how easy it was. Support also said, "If you need us, we can be on the line." We scheduled some time with them, but we never really used them.

We installed the Interactive Agents once. There was an odd case where we were trying to automate a Microsoft Access script or something, which required the Interactive Agent to be installed. This took awhile because of permissions and things like that. Once it was working, it just worked like any other JAMS job. The only hassle was setting it up. We were a bit confused by the documentation. This was at least six months back, but it had something to do with the instructions not being entirely clear as to what types of authentication we had to set up. We reached out to JAMS support, and they said, "Do this." Once we did that, it worked. That was really our only exposure to the Interactive Agents.

We did it all ourselves.

It has been a while since we installed it, but we might have had someone on the line. They actually said, "If you want, we can be on the line." We might have used that, but I don't think we really needed them because it was just click, click, click, and follow the instructions.

We have an infrastructure group, but deployment for JAMS usually defaults to a single person, since he was the one who installed it in the first place. So, he has the most "knowledge" for upgrading patches.

We haven't had the requirement to go beyond our number of licenses. The way that the license is set up, we are allowed a certain number of jobs a day. That is the license that we have, which is more than enough. 

It was $10,000 for the first year. Then, there is a maintenance cost for licensing every year that we get billed $5,000 for every year.

The way that the license is set up = it will allow you to 350 jobs a day. You can install the agent on as many machines as you want, but you can only run 350 jobs a day. Then, if you want more, you pay for more.

I looked at VisualCron. The reason why I picked JAMS over VisualCron was that JAMS got back to me very quickly. VisualCron took two days. They are a much smaller company and took a couple of days before they got back to me. Because the main thing is really the type of support that I could get, JAMS won out over VisualCron, even though VisualCron ironically looks prettier. 

The JAMS client is ugly, but I got support. With VisualCron, which I think is based in Sweden, the time difference would have been difficult, whereas JAMS is somewhere within the U.S.A. In hindsight, it is probably a lot easier to use JAMS because we are the government, so it probably looked better than if I was dealing with someone from overseas. 

Before they were bought over by HelpSystems, they were just JAMS. I spent time on quite a few phone calls with their sales rep, who won me over with their level of support. 

Biggest lesson learnt: It is critical having a scheduling tool that will show you where all the jobs are and what their dependencies have been when you are doing batch jobs. In the past, SQL Server Agent jobs allowed you to do it, but you really needed the ability to look at interdependencies between jobs. That is what JAMS gives you.

The reason why I am giving it a seven is because of the UI. If they fix the UI, I would give a higher grade than seven.

We use JAMS for technical and workload automation. It's sometimes used for transfer, but it's mostly for workload automation.

We did a POC for one of our customers recently. Our client had some SSIS packages that were hard to automate. They had to be manually executed periodically. They didn't have any automation. When I introduced JAMS, we learned how to integrate their SSIS packages. The solution made a great impression on the company.

We had a good session with the company and having or upon them having these JAMS. They have 500 different SSIS packages that need to have separate schedules. I showed them how easy it is to convert and store at a large scale. We can use code-driven automation to address complex scheduling requirements. It enables you to integrate multiple applications and API connections. If you need different kinds of schedules, you can accomplish this using the command list. That's helpful to our current and upcoming clients.

JAMS helps centralize job management because I can orchestrate different job types across multiple kinds of operating systems, including Oracle jobs and SQL jobs like the SSIS packages. Multiple types of scripts can be collected into one application. It provides a single pane of glass in its monitoring view. That's another advantage JAMS has over other solutions. The monitoring console provides the administrator with a broad overview of those channels.

When the data is ready to go wherever I need it, JAMS ensures the specific job should be executed on its given schedule. We can provide different notifications or set up recovery in case the job fails. We can always ensure there are other retries. We can configure it to run a set number of retries if needed. If the data still hasn't been transferred after several attempts, we can send an email notification to the administrator to take action. 

JAMS saves us time troubleshooting job failures. The logs are helpful, and you can select the verbose option so JAMS can provide lots of information about the issue.  It also reduces the number of monitoring tools we need. Its ability to integrate with various operating systems using its agents and database connectors eliminates the need for other monitoring tools.  Job scheduling in Linux and Windows can be orchestrated and monitored through a single pane of glass.

I didn't know about JAMS because I don't have a person with any challenges with the purchase administration. The feature or the user interface is user-friendly because of the readable icons or very descriptive icons. Although I'm a beginner user of JAMS, I did not have any issues using it. 

Whenever we propose JAMS to one of our clients, we always highlight its ease of use. The interface for scheduling jobs is user-friendly. I also appreciate its strong integration with Fortra's other tools. You can integrate it with the other products to create a total automation solution. 

I rate JAMS 10 out of 10 for its ability to make us aware of and handle common issues that can prevent jobs from running. I rate JAMS nine out 10 for exception handling. You can configure exceptions to the rules in the scripts. For example, the process might not be executed on specific national holidays or days the offices are closed. 

Our clients are impressed with JAMS's ability to operate across platforms. Most of them use Linux with a combination of SSIS or Oracle packages. If it's a Windows-only solution, the support will be very limited, but most customers do not use Windows anymore. Most of them are on the Oracle and Linux side. The fact that it's a multi-platform system helps us scale up our clients.

JAMS is highly flexible in terms of error recovery and job dependencies. That's something I typically stress in our demos. The use of workflows is easy to understand. While I don't have any experience with other workload automation solutions, I think JAMS can provide this high-end feature, where you can accumulate multiple jobs at the same time with different requisitions. 

I am also supporting and reselling Fortra's GoAnywhere MFT and am interested in Genesys' file-transfer solution of Genesys. Compared to GoAnywhere, Genesys has limited options. The tabs in the JAMS file transfer could be clearer. It would help us demonstrate to our client that JAMS not only automates jobs but also does fast transfers, and it's an alternative that supports and filters different kinds of platforms. Filtering file transfers will be highly beneficial to them.

We have used JAMS for almost a year 

I rate JAMS nine out of 10. The software is stable, but it depends on the resources of the system where it is deployed. 

I rate JAMS 10 out of 10 for scalability. Most of our clients are small or medium-sized businesses, but we have used this for government clients, so we're confident it can scale. 

I rate Fortra support nine out of 10.  The support could be better. I have a favorite support engineer, and I wish the others could be like him. When I send an email, he responds in less than an hour. With some of their other technicians, it may be 24 hours. They are very responsive whenever I send questions or technical issues to their support team.

Positive

JAMS can be installed through Active Directory integration, so it's all straightforward. Any technical team or data center manager would not have any challenges installing JAMS. Typically, we can have it running in under a week. We needed two or three personnel to deploy it. The project manager handles it and there are one or two technical staff to assist. Afterward, we need to train every person who will be working with JAMS. 

I rate Fortra JAMS nine out of 10. We recommend JAMS to all our existing clients. We have 10 to 15 GoAnywhere MFT users, but by the year's end, I expect to demo JAMS to at least half of our current base so they can see how powerful this solution is. They can have GoAnywhere for their file transfers and JAMS for their workflow automation. 

Our GoAnywhere MFT clients need to automate commands, batch file transfers, and PowerShell scripts. JAMS gives you better insights and more options than natively executing commands in Azure MFT.