JAMS Reviews

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.

We use Fortra's JAMS as our orchestration and scheduling platform to manage workloads executed on various timelines, from daily to every few minutes. Additionally, we incorporate ad hoc workloads, manually scheduled by individuals as needed.

JAMS support has been among the most helpful and knowledgeable we've ever worked with. They're always eager to assist and quickly find solutions. While a few minor issues required escalation, we've been able to resolve them all within the current version of JAMS. 

After initial misuse, we have optimized the use of several agents deployed in our environment. This improvement was made possible through collaboration with internal stakeholders and guidance on JAMS best practices. While agents might appear to directly solve user problems due to their ability to perform custom tasks on machines, in our cases, they operate behind the scenes, unseen by users.

JAMS handles exceptions well, especially when calling PowerShell scripts, successfully bubbling up errors.

It centralized our job and orchestration management functionalities into a single control plane, providing visibility into previously siloed work. This consolidation streamlined operations and enhanced oversight through a unified dashboard. Additionally, JAMS empowered us to build advanced processes by effectively managing retries, workflows, and sequences. Without JAMS, replicating this functionality would have been manual and inefficient, lacking the comprehensive visibility and control JAMS provides.

Data Slack refers to delays in data pipelines caused by disparate and siloed processes. Using JAMS, while powerful for scheduling and orchestration, can exacerbate this issue if teams break down processes into isolated tasks within different tools. This fragmentation leads to data sitting in queues and folders, awaiting processing. To improve efficiency and timeliness, it's recommended to consolidate these fragmented processes entirely under JAMS. This allows JAMS to execute the entire workflow from start to finish within a single execution, eliminating data slack and ensuring timely data delivery.

JAMS has helped save IT staff time by automating tasks previously performed with scripts, and its scheduling feature has been particularly useful.

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.

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.

We primarily use JAMS to coordinate jobs between our JD Edwards environment and SSIS packages that we had built to process packages through our SQL server. 

JAMS enables us to organize all these jobs. We have so many jobs that need to run in a specific order, and it's nice to have one place to put them instead of having to look in 18 different places. I still have jobs that aren't in JAMS, so we must go to each machine to find which jobs are running.

Before we had JAMS, we had a set of jobs running in JD Edwards' scheduling system and SQL jobs in its scheduling system. Those two sets of jobs were constantly interrupting each other. If the SQL jobs stopped running, the JD Edwards jobs would stop, so we had to troubleshoot and restart them. It was the same for JD Edwards jobs. JAMS allows us to coordinate the timing between them so the JD Edward jobs finish before the SSIS package runs or vice versa. 

JAMS has improved our productivity immensely because everything flows. I don't think we could operate at our current staffing levels without it. While we haven't eliminated monitoring tools, JAMS has freed up staff who were previously responsible for monitoring the systems. It's hard to estimate how much staff time has been saved, but we've been running JAMS for so long that we've probably saved years.  

The solution eliminated data slack because we can rerun some of these jobs as soon as they are completed, making the data more flexible and available to the end user. 

JAMS can save time when troubleshooting jobs. It depends on the case. Usually, it's an issue in the database, where someone entered an incorrect value. JAMS can't fix that because it's a human problem, but it brings the issue to our attention much faster because we get a failure report. It helps us solve the problem quicker once we notice something is broken. 

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

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

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

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

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

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

We use Fortra's JAMS primarily for SFTP file transfer.

The agents are essential because they are the core of the job scheduler process. The scheduler server only schedules the time to run the job, but the agents are the ones that execute it. We only connect to Windows systems, but it can connect to Linux systems and SQL databases. The agents have many features, including remote execution. There is so much possibility with the agents.

Running tasks help our users focus on their business processes more. Before I started using JAMS, I wasn't monitoring the server side, and I had no idea that so many file transfers go on. It's not just file transfers. So many services are running, and they need to be scheduled. There is no way a human can execute scripts, file transfers, or any process on time if we don't have a scheduler. So, the scheduler is like the company's backbone, taking care of all the processes and file transfers that need to run per the scheduled time and date.

The agents help us bridge the gap between structured batch automation and processes that occur on desktops and web browsers. I'm using it not for desktops as it is generally used; it is all about server-to-server. So, the files are created on some server and must be transferred to another server. And outside of our network using SFTP, both in and out. So, again, it's possible to execute any job locally or remotely. It can be a script. So, sitting locally or remotely, we can schedule it to run on demand, assuming it is trigger-based, like when it sees a file, it transfers by itself. Or if I email on demand, I want to run a specific job, I can email it, and then it executes that job. Or it can be time-based, like running this job every Monday at ten a.m. There are so many excellent options.

JAMS handles exceptions easily, and most configurations are straightforward. Over the past three to four years of using the tool to meet company requirements, I've always been able to find answers to my questions. I typically find a solution within the tool if I encounter an issue. The support team is also excellent; they provide clear and helpful responses, often including screenshots to guide me through the process.

It significantly reduces troubleshooting time for stalled jobs, benefiting teams like SAP and payroll that frequently transfer files internally or externally. For instance, payroll's bi-weekly file transfers to and from banks would previously consume hours when handled manually via email or other methods. Now, JAMS automates this process by retrieving files from the payroll application and delivering them to external banks. Similarly, incoming bank files are automatically fetched from their servers at specified times, eliminating manual intervention.

JAMS streamlines file transfers, saving countless hours for teams like SAP and payroll. Traditionally, tasks like sending bi-weekly payroll files to banks involved manual methods like email, consuming significant IT staff time. JAMS automates these transfers, freeing up staff and eliminating manual processes like email, ServiceNow copying, or using Box.net. JAMS recognizes a file and automatically sends or receives it whenever a file is created, saving countless hours for various departments daily.

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

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

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

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

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

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

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

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

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

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

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

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