JAMS Reviews

We have gone through a series of mergers, acquisitions, and purchases. We have had JAMS for almost eight years, and actually, I have been with the company for nine years. We have had JAMS long before then.

JAMS has become our enterprise job scheduler. We primarily use it for job scheduling. We are moving into the cloud. My company was first called First Global, then got into Blue Cora and Avantax through mergers, acquisitions, and divestitures. It seems like I have been with the same company for nine years, but my company and email changes every two years. We have had JAMS for a really long time. In the Blue Cora Avantax world, while we used AWS quite a bit, we were also quite a bit on-premises with SQL servers. Then, as we merged into another company called Blue Cora, they used to use the same JAMS-related products, which is owned by Fortra, also called Automate. We still liked or preferred JAMS over the others. When we migrated and finished integrations with that company, we consolidated everything that was in Automate into JAMS. It has been one of those solutions where we use it for enterprise job scheduling. We are heavy SQL servers, so from running our backups to ETL processing. I work for a FinTech company. Many of our processes, including file arrivals, come overnight, and then we sequence and trigger-base it. Based on times of file arrivals, we execute various tasks and then execute the ETL process to load them into the databases and then trigger it to execute. Some portions of our workload is in the cloud as well. We start some Glue jobs and other things as part of a trigger if using JAMS.

We have really enjoyed working with JAMS in terms of notifications, alerts, and streamlining. There used to be a process with Automate, which is another product from Fortra, but even before that, the other division of the company that we were merging with had a tool that was built in-house called a file handler or file distributor. It was an in-house developed tool, but it was not as streamlined or as efficient as JAMS is. We literally had to have a dedicated nighttime person monitoring. Although we are 24/7, the divisions of the company that we were using JAMS for have been small scale. While we have automated it, we have streamlined it in such a way that notifications go out and alerts go out, but if there is anything, then we get paged and alerted, and if anything needs to happen at midnight, we can wake up. On the other hand, with the tool I mentioned, the file handler and distributor, we used to have a dedicated nighttime person that had to be sitting and monitoring it to see when a file arrived, whether it met the conditions, and then execute the next particular job. By using JAMS, we have gained a lot more efficiencies in terms of all of those to streamline it, and there is no necessary need for having an overnight engineer just keeping an eye on all of this.

I have been used Jams for about nine years.

Between web apps and a couple of loads in AWS and then some of those still older technologies, it has definitely helped us.

We are definitely going through many mergers and acquisitions. As we are going through mergers and acquisitions, some of them are very smaller companies that we are just purchasing, but they might have had manual processes or things of that nature. The technology is not always upgraded. We are in the AI world, but things are changing so fast in one direction, but especially if you go through mergers and integrations, integrations is definitely not a fun field to be in. We can use AI, but at the end of the day, figuring out what the tech debt is, where everybody is at, and then at least until we understand the entire business scope, we have to just make sure to run the business as is at some point because business still needs to run. Those are situations where it has helped us to just say that we don't really care in which tech stack that we are in, whether it's latest or not, but the forward as well as the backward compatibility has been of great help.

I received a question asking whether we have received proper support within our organization. The question was asking about efficiency-wise what we have experienced internally in our organization using JAMS.

We have eliminated the in-house built tools that were called the file handler and file distributor. We have eliminated using Automate as much as it is. We were cutting two different checks to the same company, but we still eliminated Automate. We are almost near closing to eliminating GlobalScape, which is also still a part of the same company as well, because that is also owned by Fortra. GlobalScape will be eliminated, but everything will be centralized into JAMS.

The setup was tremendously easy. When I just joined a long time ago, that seems like eons ago now. We used to just deploy, and I think I was not even there during the initial planning or deployment or onboarding phase of JAMS. Lately, we have just done it, and then the imports, exports, and other things, we just make sure that it is all in there, and the deployment is through PowerShell XMLs and moving it from one environment, like dev to UAT, promote, and UAT to prod, promote, and has been tremendously fair, easy, and simple enough.

The return on investment has definitely been there, but at the same time, not going to lie, the primary factor, sometimes, if anything, that I might get pushback, especially with the newest acquisition and then the leadership, is the cost of the licensing has definitely gone up. We used to be in a grandfathered per the number of jobs run per model. We were literally paying pennies on the dollar, which was good, for multiple years. But now we are into the agent mode, considering how many agents we are running and where, and all of that too. The cost has definitely gone up tremendously. That is where I do know, as much as the feature sets are there, and if the newly acquired company is going to be doing a pushback, they might just say, 'Do we still need to pay this much? Or at that point, should we look into an alternative?' That might be one. Not going to lie, every company and every vendor is doing that, but at the same time, pricing sometimes is the one big pushback that might come back.

I absolutely will have to do an alternate evaluation. As I said, as part of those last three or four mergers and divestitures, we had evaluated. We didn't have to go forward. I think we already had partnerships with the vendor, and we just decided not to go fresh evaluation mode. But with the latest acquisition into Cetera and that as well, I am pretty sure that Cetera is a much bigger organization, and we might have to just go through, and they will just ask me to do an evaluation across the boards and then provide justification. I do have to do it when the timing is right.

I use JAMS Interactive. I have the client mode enabled. In terms of the scheduling, I am in the 7x version of JAMS currently, and I use that. I have the console or the dashboard where it just tells you where your job run monitoring is. We have not upgraded to the latest and greatest versions of JAMS, if any, because we are going through quite a bit of integrations and other things. That will have to become the next priorities. We are currently using other versions of JAMS or JAMS-related projects. Fortra as a company was using Automate, so we migrated from Automate to JAMS, but we also use their other versions, GlobalScape. We are trying to consolidate it all, bring everything into JAMS, and then go from there. From the agent aspect, I use the client version, keep where my job current monitor status is, and then release the jobs, cancel the jobs, and reschedule them.

Most of it is scheduled to run on an automated basis, but there are processes that either we have to do certain things ad hoc or we have to run manually, so we run some of those again. Those interactive agents have been tremendously helpful. For example, we have all those database backups automated and then run the fulls and the differentials during the nighttimes or weekend times. But then occasionally, let's say if I'm going to do a development or I have a deployment, our deployment windows run from Wednesdays or Thursdays in certain different cases on the later evenings on Central Standard Time after 6:00. But in some cases, let's say if it's a major deployment, we might want to take a backup just before deployment starts. We have set up jobs in such a way that the ad hoc jobs will run on an on-needed basis or I can parameterize and then say, 'I don't want to do a backup of everything, but I want a backup of this specific job.' Creating a job literally on the fly or running them on an ad hoc basis has been tremendously helpful. The interaction has been needed and is useful.

The quantifiable metrics that I can easily say is at least about four to five hours per person. I keep going back to that nightly person. The nightly person literally started his day at 10:00 and finished at 6:00. Sometimes the handoffs and lack of it was not always there. But now, with the way that we have automated it in such a way and then sequencing of those things based on file arrival, some of those file arrivals start coming as early as 8:00, but then we were able to program it and stagger it in such a way that the next most important file that comes is closer towards midnight, a couple of minutes plus or minus before or after. Of course, it is coming from the vendor. We have been able to schedule it in such a way that there is nothing really that needs to start at 10:00, but wait for all these files. But the moment we start getting this file, sequence it, run it. If something gets delayed, don't wait, just send us a text so that we are on high alert, so we'll meet that 6:00 AM, 7:00 AM Eastern SLAs. Sequencing and parallel threads and things of that nature definitely give about four to five hours per day.

A couple of times, in a few instances, there are some jobs that we have asked that based on certain scenarios we want it to repeat or run multiple times during the day, and those feature sets or requirements are there. After the last completion, run it after every two hours or two and a half hours, those kind of situations we have been able to get accomplished in a simpler way without making too much code difference, but the repeat processes, JAMS does have the feature set to make those possible.

As far as if you just sequence it or ask it to run parallel, or at least I'm evaluating it when compared to an Automate or the in-house built tool and other aspects that I have just seen, it has far exceeded how it has performed when compared to the other tools.

Blue Cora used to have two holding companies. One is called Avantax, so I would still kind of put Avantax in there, but our licensing with JAMS itself is established under Blue Cora.

The interaction and things with a little bit of old tech as well as in between the new tech, meaning even within the AWS, like pushing a file, for example, you could still be on-premises. Once you get it into on-premises, push a file into S3 or do those kinds of things, and a trigger or start a Glue job and other things. Those experiences and these interactions have been there, and making API calls. All those features are out there, and it is simpler too. You don't need a dedicated specialist domain expert or something. Somebody, even a newbie, can be taught and will be able to pick that up easily. This is one of those great tools with not much of a learning curve and something easy to implement and has tremendous potential.

There are, depending upon which SQL Server editions we got in there, and the SQL Server Agents, for example, could be something that we have had batch jobs. Some of those jobs, whether we use it for CDC captures or some SQL Server logs, whatever. We are just trying to do what those agents have been set up for, and some of those jobs have been set up in this older, but again, smaller acquisitions companies, if they are coming into the SQL Server Agents, they never had this enterprise scheduler like in JAMS, but they would have been just running because they may or may not have had a dedicated DBA, that kind of a thing. Simple enough, a developer might have scheduled something in a SQL Server Agent, and then we just try to automate it and then bring it in and coordinate it with JAMS. The same situation applies for the Task Schedulers too. Not everybody had JAMS, but especially as part of these integrations and these smaller acquisitions that we are able to do and triage and manage it and make it as, 'Now we have this big holistic view and here is where everything is running.' Those are the things that have been tremendously helpful for us with JAMS. Overall, I would rate this product an 8 out of 10.

Our main use case for JAMS is to automate our data pump backups for our PeopleSoft Oracle system, as well as run a myriad of different processes that we want to schedule related to integrations that have dependencies based on other jobs. We also use JAMS to do our database refreshes for a weekly REL, HCM, and Finance environments that we have to do a database refresh. There are approximately 32 steps, and we use JAMS to manage each of those steps in an automated fashion.

A specific example of a process or workflow we're running with JAMS involves our zero-tolerance firewall, making it very difficult to move a production data set or dump files across the network to non-prod environments, with REL operating as a production-size database. However, it is in the data center with the non-prod environments. It is production size, so we use JAMS to get around that process to be able to move files to a file server and then move them from there to where we need them to be. We go through moving the export files, use JAMS to unzip those files, export our local PeopleSoft configuration for each of the environments, including security and things of that nature, and then we drop all the SysAdmin, performing a schema refresh of the SysAdmin schema. We drop all the schema objects, shut down the application and web server processes (some on Windows, some on Linux), do a shutdown restart of the database, and then import the data. We re-import our local configuration that I mentioned before, perform some purging of app messages, update the developer roles from a security standpoint since we're moving from production (the source) to REL (the target environment) that is production-like but has very different security. After that, we clear process scheduler reports, take care of any PHI or anything related, update emails to ensure we're not sending any to our production clients with a generic email those processes use, run stats on the target environment, start the application and web servers associated with that environment, export the files, zip them up, and send out an email to the team to let them know the refresh is complete.

We also use JAMS to maintain our RMAN archive logs, ensuring those are taken care of. We use it for anything long-running, receiving notifications if something runs longer than it normally does. We update synonyms, perform data pump exports, rotate alert logs, clean up the Oracle U01 file space (the home directory for Oracle), and export out a copy of any errors from the alert logs so that we have that information emailed to us. This is part of what we call our daily health check, where we do a number of things to get information into an email and our daily health check so that we don't have to physically go to the server and sign on to see some statistics that might be related to the host or the instance.

JAMS has positively impacted our organization by saving us time, reducing errors, and improving workflows. We are not just using it in the Oracle PeopleSoft environment; on the Epic side of the house, we have multiple processes, setups, and jobs running to move files around. As an organization, multiple DBA teams, including the Oracle PeopleSoft, the Epic DBA team, and the SQL Server DBA team, are using JAMS in similar manners.

JAMS has freed up time, serving as a single source for multiple teams within our department, though I cannot quantify exactly how much time. It is apparent to anyone you ask in the organization that we are saving time by utilizing JAMS.

The best features JAMS offers for our team include the ability to get information emailed to us in an automated fashion based on schedules we have set up with a lot of flexibility regarding when and how we run them. We include dependencies in many of these jobs, so one setup inside of JAMS does not execute a job unless there are certain dependencies. We also utilize the aspect of JAMS that allows us to time a job; if we know a job runs within a couple of hours, we can set limitations to prevent it from becoming a run-on job. If something hangs in the network or there is an error, we use that portion of JAMS to tell the system to proceed to the next step, realizing it is running beyond the normal standard time.

JAMS helps centralize the management of jobs across all our platforms and applications, which is important because we have multiple teams using it. This centralization allows us to have a single point for management and reporting, so it has been very helpful in that regard.

JAMS has handled and automated complex scheduling requirements, as we have multiple systems requiring dependencies and different criteria for when something executes and how long it is allowed to execute. That automation has been extremely helpful.

When it comes to improvements for JAMS, I think upgrading and migrating some of the current processes could benefit from possibly having a multi-window setup so that you can see both the setup and the job itself, along with the code, without the need for multiple windows. It would be really nice to have both things available in front of you where you could see the log file and the results of any changes you make to your code.

I have been using JAMS for approximately four years.

For the most part, JAMS is very stable. Occasionally, if you leave multiple windows open over a period of time, it is necessary to end that task and restart.

To the best of my knowledge, we have been able to scale JAMS as needed for our purposes.

I have not had very many reasons to call customer support; it has been fine in the cases where we reached out, but there have not been many reasons to contact them.

I do not believe our organization migrated from another solution, as I was not here at that time and do not have any further information to share. I do not believe we previously used a different solution; I think we implemented JAMS for the purpose it was intended.

My manager has mentioned many times that they did a comprehensive review before choosing JAMS. However, I was not involved in that process.

I do not have any hard evidence regarding specific outcomes or metrics, but it is very obvious from the time I have been here—prior to that when JAMS was implemented—that time savings issues were buried in paperwork and are not something I have had an opportunity to go back and review.

I believe the pricing and licensing were fair. I was not here when that process took place and do not know exactly, but I have not heard anything negative regarding the pricing. As we are also going into a merger, joining two organizations, the pricing for adding on that additional hospital has been fair and we are moving forward with that project. To the best of my knowledge, the pricing and licensing have been reasonable for Rady's.

JAMS has helped notify and handle common issues that prevent our jobs from running, as we have a number of processes currently using it that give information related to specific jobs or setups running in JAMS. We use that extensively on a daily basis.

A perfect example of JAMS helping eliminate data slack across applications is our database refresh that we perform on a weekly basis, where our development team tests some of our most current changes in the environments.

My advice for others looking into using JAMS is that if you have complicated processes and scheduling requirements with dependencies across your enterprise, JAMS would be a tool I suggest they consider. It allows you to code in shell script, Python, and offers a lot of versatility for getting your tasks done. I would rate this product an 8 out of 10.

My main use case for JAMS is to manage over 6,000 jobs to schedule on a daily or weekly basis, which include different types of jobs such as Python, Linux scripts, and more.

JAMS is used for monitoring purposes, as we have scripts running every five minutes that check the stability of our systems.

JAMS offers diverse scheduling capabilities for any kind of job, including Linux, PowerShell scripts, and SQL, enabling automation of jobs, which has proven beautiful after three years of usage. The UI is very friendly, specifically in version 7.0 onwards, and it's a very stable product with few observed problems. The documentation is neat and clear whenever needed, providing exactly what we seek, and the support team at JAMS is really helpful, replying within two to three hours, which is greatly appreciated.

The feature I rely on most day-to-day is the concept of having a sequence of jobs. This simplifies scheduling for clients by allowing us to create a sequence that includes all jobs for that client. Whenever a new job needs to be scheduled, we create the job and add it to the sequence without much hassle.

JAMS has positively impacted my organization by completely removing the headache of scheduling jobs, not just for the organization but for all internal operations teams need. As an SRE, I write numerous scripts in different languages such as Python, Linux, and PowerShell, which I can simply schedule on JAMS, helping us sort out tasks efficiently.

JAMS could be improved with a web client that is accessible and as fast as a normal website, eliminating the need to RDP to the servers to access the JAMS client.

A functionality running on the JAMS server to continuously check the JAMS agents would ensure they are working properly. If an agent is not responding, a feature to restart the service from the job server machine would be beneficial.

The upgrade process, particularly when switching from V6 to V7, could be clearer in terms of documentation, ideally with screenshots showing exactly what needs to be done on each screen.

I have been using JAMS for more than three years now.

In my experience, JAMS is stable.

JAMS's scalability is noteworthy; we run 6,000 jobs per day without facing any problems, so it handles growth and increased workloads effectively.

The customer support is excellent; they are fast, technically strong, and the people I've interacted with know what needs to be done.

Positive

I had my first interaction with JAMS in my current company, where no prior automation or third-party tool was used, as we relied solely on writing scripts and manually scheduling them on Linux or PowerShell.

JAMS has helped me save about 40% of my time specifically related to scheduling or script tasks in my daily work. The design of JAMS makes it very easy to copy jobs and make minimal changes while ensuring functionality. The architecture of JAMS is neat and clean, enabling us to run agents on different machines while having the job scheduler and servers on one machine, which simplifies understanding its operations and helps in troubleshooting.

I did not evaluate other options before choosing JAMS, as it was already in place when I began.

If you have a huge number of jobs to schedule, you can definitely opt for JAMS. While I'm unsure about the costs, JAMS is especially beneficial for those needing to manage a large volume of jobs. I rate JAMS 8 out of 10.

There are many types of use cases for JAMS. I get to know about Gemini and Google Cloud SDKs, which I use in making my projects for hackathons and my portfolios.

By using JAMS, my company has seen benefits such as getting to know about Google products and the latest features that are newly launched by Google. Additionally, they help me in building my projects portfolio and engaging with knowledge. I participated in many types of quests and seminars where I learned more about this, and I was also a speaker there so that I could explain what JAMS is and what the Google tools are.

JAMS helps notify and handle common issues that prevent jobs from running because when we use JAMS, we get to know about Google products and there is also a feature of Google Cloud notification. From there, the notifications are about open job roles, new job quests, and many more things that today's HRs use to build new jobs.

JAMS helps centralize the management of jobs on all my platforms and applications.

JAMS helps save time when troubleshooting stalled jobs because it provides troubleshooting features. If any of the programs are debugged or errors occur, then troubleshooting clarifies them.

I would enhance the compatibility feature of JAMS because sometimes when the server is under high load, it does not inform us and we cannot get answers. It often tries to give irrelevant answers, so I would improve that compatibility of JAMS.

I have been using JAMS for about two to three months. I completed all the JAMS labs in one to 1.5 months.

When I use JAMS and the troubleshooting method, it takes one to two hours to resolve problems. However, when the servers are under high load, it can take more than one day sometimes.

My company did not migrate from another solution to JAMS.

I have experience with the pricing, the setup cost, and the licensing, and I find it to be good.

I did not see a return on investment with JAMS because I did not invest in any type of JAMS. When the Google Cloud study JAMS arrived in India, they provided free credits to use JAMS products.

I have experience with the pricing, the setup cost, and the licensing, and I find it to be good.

I evaluated many types of questions about how to build AI automations before choosing JAMS. I found that many features did not work properly when trying to make AI automations without JAMS, so I took the help of Gemini and all the Google Lab products that helped me build proper AI automation.

I appreciate that JAMS has a very familiar UI because it is not complex. Every child, meaning 15 to 20 years of age, can easily use JAMS because the UI feature is very good and very eco-friendly for students who are going to use JAMS for the first time. I also appreciate the temporary user ID and address feature because it is very safe and secure.

I sometimes use JAMS' interactive agents because I have made projects where I did not get the code properly. I used Google Gemini according to JAMS where we get information on how to use Gemini for the project. That is how I leverage JAMS' contribution toward my project.

It is important for my company to use interactive processes because people who want to work with Google can collaborate and contribute toward JAMS, as it gives the best types of knowledge for today's and future curriculum of AI and development technology.

Running interactive tasks helps users focus on their business processes because according to the automations that we use in today's world, this can help in the business field.

It is important in my company because when we get new buyers or new customers, automation helps us very quickly and is very helpful for us. In the absence of any types of people or employers, we get this automation done in their work on their behalf. This is majorly important in today's time.

JAMS' interactive agents help bridge the gap between structured batch automation that happens on desktops and web browsers because they allow people without knowledge of coding or technical skills to use these types of agents to interact with them and also use JAMS products in their work and business.

I would rate JAMS' ability to handle exceptions between 9 to 9.5 because when I use JAMS, I get rid of all my problems by using the Google Cloud Labs in JAMS.

JAMS' code-driven automation has helped handle complex scheduling requirements because it helps in complex problems according to each person's need.

JAMS has helped eliminate data slack across my company.

It is important for my company that data is ready to go when users need it because we use JAMS products and prototypes in our company's database since it is eco-friendly and easy to use, without complex debugging issues.

JAMS helps to eliminate monitoring tools because it makes our work easier, so we do not need to buy some subscriptions, which means it eliminates them.

When I use JAMS, it helps me eliminate tools that sometimes make mistakes. However, due to JAMS, I get to know about products such as Gemini and other Google software, including Google Colab and Google Cloud Labs, which make my work easier, even compared to paid platforms.

JAMS has helped to free up my IT staff's time.

It has freed up enough time because it is eco-friendly and easy to use, which is why it helps.

I would advise companies considering JAMS to allow more time for study, as not only two to three months of evaluation might be insufficient. Sometimes students or beginners may not get the full information about JAMS in that timeframe, requiring them to wait for another cohort or another year. I suggest they should provide more free service and time for users to enhance and utilize all features of JAMS. I would rate this product a 9 overall.

My use case is in batch scheduling and managing the batch jobs.

The best features of JAMS are that it is very user-friendly and not so complex. JAMS is not as complex as other tools, so we can easily get over with the tool.

Since implementing JAMS, I see a lot of improvement because they issue multiple new versions of the tool every three to four months. We usually upgrade it, which is a good thing, so we don't need to wait for a longer period of time to get our issues resolved.

JAMS does help notify and handle common issues that prevent jobs from running, which is time-saving for us. We do not need to wait for long hours; we get notified immediately, and that's a good thing. It also reduces the manpower, as there's no need for manual intervention in those cases.

JAMS helps centralize the management of jobs on all of my platforms and applications, which has helped my organization significantly. Everything is getting centralized now and all comes into the same place, where we take care of all the batch monitoring and everything. We know when and where the jobs are executing, which jobs are executing, and who is responsible for the jobs, giving us higher visibility and better handling of the batches.

Since JAMS itself is the tool that we are using for monitoring, it has helped eliminate any monitoring tools we previously used. We can see all the batch execution status within the tool itself, which saves money, time, and cost, allowing us to handle everything in one single tool.

An area that has room for improvement is related to the AWS RDS and database part, where they said that is in progress and they will be bringing it in the new version. It is handling the database in the Azure cloud environment as of now.

I have been using JAMS for the past four years.

In terms of stability, JAMS is a stable solution, and I would rate it as nine.

For scalability, I would rate it as seven because when we have a huge volume, sometimes the tool is not so responsive.

I would rate the technical support from the vendor as eight.

Positive

I have tried other solutions including Control-M and workload automation tools from other vendors.

The deployment was easy with not much complexity involved. We had good support from the vendor, so it was easy. We did it with the development area first, which took around two to three days. Initially understanding the requirements and building up the servers all took around two to three days to install everything. For production, it was easy since we had already done it for development and knew how it had to be done, so for production, it took around one day.

JAMS does require maintenance, as we do patching on the servers where JAMS is installed. Other than that, we do regular upgrades whenever the new version of the tool comes into place. It is not complex to do maintenance; in fact, it is easier. Everything is a direct process, and we have proper documentation in place, so it is not complex.

I would say we have seen a 30% return on investment because we had multiple tools in place previously, and now we have stopped using all those tools.

My thoughts on the pricing of JAMS are that I won't say it is cheap, but it is cost-efficient, and that should be acceptable.

I do not regularly exchange files with vendors or customers because it is basically for our internal use. We have all the things within ourselves, not like external things, and there is not much file transfer within our tool.

JAMS has not helped handle complex scheduling requirements, as we usually don't use more code-driven scheduling. We always go with the sequencing and other GUI options and have not gone into that code-driven part.

It does not take much time when troubleshooting stalled jobs, as we can see all the error logs and everything within JAMS itself, making it time-saving. If a job fails, we can check the errors and logs within a few minutes to see why the job failed, which saves around 20% of our time.

Approximately 30 to 40 users work with JAMS in my organization.

The migration process to JAMS is moderate, not easier and not difficult, because a few processes are easy and a few processes are a little bit difficult. The processes I would consider on the more difficult side are some complex processes where we have to run some APIs or run some things in pipelines which are in Azure or AWS, as it requires a little bit of modifications and other things.

I would recommend this product to any users, especially for medium or smaller enterprises, because in terms of a huge volume of jobs, sometimes the tool gets a little slow in response. For medium and smaller enterprises, it is a very good tool; however, for a bigger environment, I am not sure how good it is.

My main use case for JAMS is to install, set up, and configure for customers working with JD Edwards application.

A specific example of how I use JAMS during an install or setup for a customer includes setting it up on a JD Edwards system with the JD Edwards batch server agent and using the run UBE command to submit the jobs remotely from JAMS. I then set up jobs in JAMS and configure sequences.

I also add some high availability options to provide solutions for having redundancy with multiple batch servers, including leveraging JD Edwards virtual batch functionality.

Implement at customer sites rather than for ourselves however it improves on management of JDE batch processing and overall management at customer sites.

In my opinion, the best feature JAMS offers is enterprise-level scheduling.

What stands out to me about the enterprise-level scheduling is that it's relatively straightforward to set up, straightforward to copy and create new jobs, and I can easily understand how all my jobs are set up and configured, monitor them, look at their history, check the logs, and track what's going on across the system while also building in dependencies.

JAMS positively impacts my organisation because it helps make it easier to manage JD Edwards scheduled jobs and fills the gap that the JD Edwards application has with scheduling, resolving a lot of those issues.

To improve JAMS, it should resolve the issues with the JD Edwards application and the need for the SSH client connection in the current version, which has been a problem for a while. I suggest implementing tighter integration with JD Edwards virtual batch, catering for multiple batch servers in production versus non-production and different server maps.

Getting bug fixes pushed through into the product has been quite difficult, which has been challenging.

I have been using JAMS for over 7.5 years.

JAMS is very stable and we've seen minimal issues with the applications stability.

JAMS has some scalability even without the enterprise scalable options. We have been able to leverage the agents and hook into the JD Edwards virtual batch and that configuration, performing quite well.

The customer support is very good, reasonably quick, and very personal.

We have worked with other business partners and looked at other solutions, but JAMS was the recommendation solution based upon our analysis and the features and functionality of the production. I have worked with Tidal previously and had some exposure to RevSoft. Tidal was very good but very expensive, and JAMS looks like the best product that works with JD Edwards and also had some local contacts who I've worked directly with and this has helped with the relationship.

We were more of a business partner. However, as I mentioned before, we have looked at Tidal and RevSoft and some other solutions we have seen out there, but for any kind of enterprise scheduler with JD Edwards for any of our customers, we mainly look at JAMS first.

Relatively straight forward but need to leverage the knowledge base for additional support or client specific requirements.

I probably do not have visibility regarding a return on investment. Obviously, the expectation is that there will be a return based on the product and the benefits it has.

I was not really involved in the pricing, setup cost, and licensing at that level. I am more involved in the technical side rather than the commercial side.

Considered other products however costs and local support were a big factor after comparing technically

JAMS helps notify and handle common issues that prevent my jobs from running. The notifications help to a certain extent, although it could possibly add further details in the email, which would also help.

I have not had experience with the code-driven automation, although I have heard of it. I am predominantly working with the JD Edwards application, which is fairly straightforward.

JAMS does help centralize the management of jobs across all my platforms and applications. It is very important because I predominantly work with the JD Edwards application, but I have customers who leverage it centrally, making it a lot easier to manage and also have dependencies on different types of jobs, maybe hooking into third-party integrations.

JAMS helps eliminate monitoring tools regarding the status of JD Edwards jobs, which are not very good at all built into the application. Thus, we have to set up custom scripting and jobs to capture that information. JAMS provides all of that and access to the JD Edwards logs as well as the JAMS logs, all in a central location.

My advice to others looking into using JAMS would be to review some of the documentation on JAMS, look at what it can do, consider the AI capabilities in the newer version, and evaluate how many agents they actually might need versus what they might have sold to ensure the correct number of agents based on the number of environments they want to set up.

I would rate this product an eight out of ten.

My main use case for JAMS is scheduling, which is the primary usage. I am mainly using JAMS for scheduling various jobs of all kinds.

I onboarded JAMS when I developed our custom framework of components, and I was not relying on JAMS capacities at that time. Since then, I have primarily utilized JAMS for scheduling a variety of jobs.

The best features JAMS offers in my opinion allow me to create dependencies to set very complex sets of jobs to run them in a particular manner. This is what I love JAMS for.

This feature helps my team day-to-day by running hundreds and hundreds of jobs on JAMS in a timely fashion, which is extremely important and sensitive, providing a lot of reporting to the entire firm and beyond.

JAMS definitely centralizes the management of jobs on all my platforms and applications, and it is extremely important because it helps to run a variety of jobs on different platforms and applications. That is why I value JAMS.

I appreciate the constant improvements in JAMS, its reliability, and it is a very powerful engine. I JAMS for that.

JAMS has greatly improved my ability to schedule jobs and relieved me from manual execution by approximately 50%.

I am fine with what JAMS offers and have nothing to suggest for improvement.

JAMS' code-driven automation is not widely used in the present environment, because I use my internally built framework components. As such, JAMS' provided code-driven automation has not been used.

I have been using JAMS for more than 10 years.

JAMS is stable.

JAMS is scalable.

If I come across any potential or real issues, JAMS support always addresses them, which definitely helps.

JAMS was a great improvement over what we used to have before. We had a scheduler called 24/7, and it had a lot of issues, but JAMS runs seamlessly and very efficiently.

Prior to JAMS, I had a different scheduler which was not satisfactory. It was 24/7, and it was not running smoothly. JAMS helped me a lot.

The overall migration process was easy because JAMS' support team provided all necessary documentation.

I have already shared the metrics that it saved IT time by 50%, and I think that is the most important improvement.

My experience with pricing, setup cost, and licensing is that the pricing was acceptable. I have gone with JAMS licensing for years now, and I am happy to have it.

Before choosing JAMS, I evaluated other options. I looked around at what is presently employed in the industry and identified JAMS as my best solution.

JAMS has positively impacted my organization in all of the above aspects. I give this review an overall rating of 9.

JAMS is used in my company for scheduling jobs like copying files from other customers to my company and to other databases or other systems.

My company has been using JAMS for quite a few years now, and I think it's really good for running long running jobs.

We exchange data files with customers every day, so we have critical, mission-critical jobs involving customer personal data and accounting transactions being in a finance industry.

We haven't gone that far yet. It's pretty much a very basic job, collecting information and transferring files.

I wouldn't say we've implemented advanced features yet because currently it's still very basic, just data transfers and storing locally on disk. We have other tooling for that.

I think what is good about this product is that it's a very well-consolidated tool that is on-premise, which includes scheduling jobs with support for Python. It also supports making API calls to cloud services like Azure, which is pretty much the main use case in my company. JAMS also has built-in SQL command lines, which attracted my attention as well.

The major benefits I see are the ease of management and having no scattered jobs around using different tooling. If this is an environment where you don't need a DevOps engineer or it's too expensive to operate with a DevOps engineer building custom pipelines, this tool is amazing. The best use case is usually for data engineers and data analysts who are not full-time or hardcore specialized developers. This tool will definitely help them a lot.

We have our own banking regulations in Australia, and we definitely have our own custom regulations and auditing involved. What I see as good about JAMS here is that it has all the trails of logs for each job run. That's very important.

Generally, with the audit logs and trace downs and email alerting, I think that's very handy to have for a non-developer centric kind of environment to run jobs.

The key benefits about JAMS is having the ability to run long running jobs on-premise as compared to products like Azure Data Factory. Azure Data Factory probably costs a few thousand per run depending on how parallel the job is. However, JAMS is different. It's licensed using a per license model.

I would definitely love to see a GitHub integration so that all the code written by developers is integrated with it. The jobs could be running the latest source code rather than the custom way we're doing it at the moment.

Not directly at the moment, but I'm looking forward to GitHub integration. I think a JAMS partner or sales manager that contacted my head of department mentioned that there's a GitHub integration coming in September, so I'm really looking forward to that.

Monitoring is not heavily used in my company.

Most of our services are in the cloud, such as Azure, which have their own monitoring in place, so we don't use any of the monitoring in JAMS.

Unfortunately, the monitoring features are not used as extensively as I think the tool is capable of. That's where I'm looking at hopefully having my colleagues venture deeper into all the other components, maybe the SQL server and Python integration.

Right now there's not much of an Azure integration with JAMS at the moment directly because we run separate pipelines. We were trying to revamp everything to use Azure Data Factory, but it's not cost-effective, and there's also data governance requirements that I foresee. Having JAMS is much more feasible with on-premise data needing to be on-premise.

I just started using JAMS about two months ago, from last month onwards and this month.

I contacted the customer service team when I requested a license key for the developer edition. There's a sales representative locally in Perth from JAMS that reached out to me. I also raised a ticket to the support team in JAMS scheduler, and I think they are very helpful and amazing.

We partially use another product called SAS as a scheduler. However, what I envision is to have SAS run everything because it's a simpler platform environment and it's much more open, having support for other programming languages like Shell, PowerShell, and Python scripts.

There's a mixture of SAS product, Azure Data Factory, and also Microsoft Fabric being used in our organization.

I think I will probably recommend others looking at JAMS for a hybrid architecture integration to run jobs with Azure cloud services or AWS or GCP or any cloud provider that they have. I think this is the bridge to all these services. Looking at the roadmap of JAMS scheduler, I see they are introducing more cloud integration. It's moving in the right direction, so having Git integration in the September release is very exciting. JAMS is really forward thinking.

We mainly use JAMS for monitoring purposes, to schedule, unschedule, and properly time the jobs at specific times they need to run.

From my project perspective, there are numerous setups and jobs that we run on a regular basis. For example, a setup name would be SYSCFG, and under that setup, there are numerous jobs again.

I can describe the bifurcation with an example. There are thousands of jobs, and within those thousands, there will be hundreds of jobs under one setup. As mentioned, SYSCFG is one setup name, and under that setup, we have around 200 to 300 jobs. Another setup name is METOP, which follows our naming conventions in JAMS scheduler, and we have defined the resources with the setup name.

The main expectation from our project is timely delivery, where we schedule jobs at specific times, and the jobs get triggered accordingly. Once completed, the data is delivered automatically into the tables, and users can access the data from the database.

JAMS offers features that stand out, especially when compared with Control-M monitoring tool, where JAMS is easily accessible and simple to understand regarding the setups and jobs being bifurcated, and we can bifurcate accordingly.

JAMS has been a beneficial monitoring tool for our project in terms of being able to deliver data that is essential for users. The jobs we trigger run on JAMS, but in the backend, they run in Informatica or in SAP. From this perspective, we have been able to deliver goods and services in a timely manner using JAMS.

As far as we are using JAMS version 6, it looks good and there is nothing major to add about it. Everything is functioning properly.

From the past three years, it has remained the same, but sometimes we face issues. If around 5,000 or more jobs run at a time, JAMS slows down, and we have to wait around five to 10 minutes or restart JAMS scheduler services. After restart, the services will be up and running, and we do not observe any delay.

There is scope for improvement, specifically when there are a larger number of jobs running, as JAMS becomes slower. That is one area where it can be improved. Apart from that, creating resources, adding resources, creating setups, adding setups, or adding jobs, everything functions properly.

I have been using JAMS for the past three years.

Sometimes we experience crashes or downtime, but JAMS remains stable as far as I know.

JAMS can handle jobs effectively, with the only issue being occasional slowdown during heavy loads.

I have interacted with the support team regarding an issue where we canceled a setup but were unable to cancel it in JAMS. It was showing as canceling, but the status was not being updated. We contacted JAMS vendor, who guided us through the necessary steps, and after following their guidance, everything was resolved.

Positive

The project requirements determine the solution used. Previously in our project, we used Control-M as the scheduling tool, and after my project changed, I have been using JAMS monitoring tool for the past three years.

The setup primarily focuses on smoother scheduling, with jobs running at particular times. I did not observe any return on investment because access to pricing, setup cost, and licensing information is limited to higher management levels.

If anyone asks for advice about using JAMS, I would recommend it as a monitoring tool where everything operates smoothly and effectively, and it is a reliable product that we can use.

The factors which I have shared would suffice to summarize what JAMS offers. On a scale of 1-10, I rate JAMS a 10.

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.

I appreciate JAMS for its readily available templates that allow me to create and deliver stand-up presentations within minutes quickly. This efficient feature has been invaluable, enabling us to streamline our workflow and enhance productivity.

JAMS' flexibility by allowing the use of PowerShell scripts adds to its value.

The monitoring of the JAMS product and its performance is an area of concern for me. I also need better tools to adopt version seven. Another area for improvement would be the addition of source control for jobs internally, as this feature would solve several problems for me.

JAMS has some quirks. It has a bit of a learning curve.

Some exceptions are not intuitive, such as when a job is terminated due to exceeding its defined runaway time limit. This generates a misleading exception message that is difficult for new users to understand and requires experience to interpret correctly.

Stalled jobs present a unique challenge, particularly when pushing a system like JAMS version six to its limits. While rare, these instances occur when jobs become unresponsive despite appearing in API queries but not in the monitoring console. Although workarounds exist, they highlight the need for improved native monitoring capabilities within JAMS. Currently, the system assumes flawless operation, necessitating supplemental monitoring tools to detect issues like excessive pending or stalled jobs, ensuring timely intervention by our teams.

I've been the platform owner of Fortra's JAMS for four years now. Before that, I used JAMS at Fortra for several years.

Through our outdated JAMS version 6 installations, we process approximately half a million executions per hour, significantly exceeding the supported capacity. Despite surpassing the rated limits by five times, we generally maintain stability. However, we experience periods of major incidents annually due to capacity constraints, which result in job failures. These performance concerns are attributed to the high execution volume. Conversely, our version 7 environment, which handles fewer jobs, has proven to be much more stable.

If I am below those capacity issues, JAMS scales very well. However, at higher capacities, like over three hundred thousand executions, there are significant performance issues.

The customer service is of high quality, and their response is prompt, exemplifying how support should be.

Neutral

The initial deployment of JAMS is deceptively easy. However, there are some caveats, particularly regarding SQL permissions when setting up the database, which my team encountered. Beyond the permissions aspect, the process is straightforward; my team completed the initial setup in less than a week, with most of that time spent resolving permission issues. 

I have experience with Ansible, which can handle similar workloads as JAMS. Both have their pros and cons.

I would rate JAMS a six out of ten. It is a solid platform with caveats in scalability.

First, understand the inheritance system in JAMS, as it is not apparent. Then, consider using execution methods to streamline processes and reduce variance between jobs.