JAMS Reviews

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.

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. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Positive

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We have 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 Fortra's JAMS as a job scheduling tool for state agencies across the country. We primarily use it for scheduling jobs and development tasks related to taxation processes.

I find the historical tracking feature of JAMS invaluable for reviewing past events. Customizable workflows with dependencies and variables allow for more complex task management. Additionally, notifications through JIRA and excellent customer support enhance the overall experience with the software.

Improvements could be made in the service desk's knowledge and communication skills among engineers to better address customer needs and ensure issues are fully resolved. Additionally, reintroducing or offering a mobile platform could enhance accessibility and usability for users.

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

We haven't had any stability issues with the solution so far.

Scalability in JAMS could be improved by enhancing word-of-mouth marketing and providing more training or demo videos for new users. Additionally, incorporating performance monitoring features could help users better scale their usage of Fortra's product.

Tech support for JAMS is generally good, with responsive and helpful engineers. However, there have been instances where the initial engineer wasn't able to address the issue and needed to escalate it to another resource. Overall, I would rate the support as an eight out of ten.

Positive

The deployment of JAMS was straightforward once we bought the solution. Additionally, the sales team responsible for handling licenses and project costs was also easy to work with.

I rely on JAMS to help me identify and address common issues that may prevent jobs from running smoothly. I typically start by checking their support site and documentation for solutions. If I can't find a solution, I search for existing tickets or create one myself. It would be beneficial if JAMS provided a community forum where users could share and resolve issues together, enhancing support for all customers.

Agents are crucial for our organization as they enable us to scale and balance processes across multiple servers. They effectively bridge the gap between structured batch automation and tasks happening on desktops and web browsers. However, we encountered an issue with a specific server's agent, which was initially challenging to diagnose. While JAMS eventually identified the problem as a database issue, there was some initial uncertainty about the cause. Overall, while agents are valuable, there can be challenges in fully understanding and addressing issues related to them.

JAMS handles exceptions effectively, but it requires users to have programming knowledge to implement them. It is not a no-code or low-code product, so users need to understand programming languages to utilize its full capabilities. Simplifying this aspect could make it more accessible and user-friendly.

Centralizing job management across all platforms and applications is highly important to our organization. It ensures that schedules and processes are properly handled, which is critical for both our customers and the public, especially for public-facing processes. Effective management reduces the risk of errors and enhances accountability for all stakeholders.

JAMS's code-driven automation is beneficial for handling complex scheduling requirements. While the website documentation may not cover all scenarios, support tickets allow engineers to assist. However, the quality of the response can vary based on the engineer's experience, leading to different levels of resolution.

JAMS saves us a significant amount of time when troubleshooting stalled jobs.

JAMS has helped us eliminate the need for monitoring tools like AutoMate. AutoMate was a simpler tool we used in the past, but JAMS provided more advanced features and functionality.

JAMS has helped free up our IT staff's time by automating tasks, which reduces the need for manual QA and troubleshooting efforts.

Before purchasing JAMS, new users should consider the scale of their operations, including the number of jobs, servers, and agents needed. Understanding these factors will help determine the budget and ensure the system meets their requirements.

Overall, I would rate Fortra's JAMS as a nine out of ten.

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.

Automated Scheduling of Tasks

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 are top-notch. I can say I have a job that's failed because of something, and they can 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. 

I've been using JAMS for 5+ 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 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.

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.