What is our primary use case?
We use it to schedule batch jobs. Batch jobs are a combination of SSIS jobs, which is actually our group's main use case. I brought it in mostly to schedule our SSIS batch jobs. Then, there are other groups who are using it for SQL Server stored procedures. We also have another group using it for a few Python scripts and FME, which is a different type of ETL tool. So, we are using JAMS to schedule those four types of jobs as well as a bunch of FTP jobs.
The application developers have been doing a combination of migrating some of their older jobs, like Python scripts and SQL stored procedures, and FME jobs over to JAMS. Any new batch jobs that they are creating default to using JAMS. They mostly do interactive online type applications. However, on occasions where they do need batch processes, they just use JAMS.
How has it helped my organization?
The fact that we no longer need to use Excel spreadsheets is huge. Before JAMS, every group was keeping track of their own batch jobs. Nobody really knew what the other jobs were. So, if jobs failed, other groups wouldn't necessarily know. With JAMS, everything is done through a single scheduler. You can choose who to notify.
What is most valuable?
The ability to work out dependencies between jobs is the most valuable feature, which is actually the main reason why we went with JAMS. We went from everybody trying to keep track of stuff on Excel spreadsheets to being able to see things graphically, and say, "This job should not continue or start unless another job begins." That is very useful. Plus, we have a bunch of jobs that are using File Watchers. So, the job doesn't start up until a file is put on a shared drive, which is the automation that JAMS provides that the old SQL Server agent did not do at all.
It provides notifications.
The fact that JAMS provides metrics is actually nice, although this feature is not really used that much. Before it was a lot harder to get metrics, whereas there are now metrics if we want them.
What needs improvement?
The client needs a complete revamp as it is not the most intuitive of methods of setting up jobs. We have encountered situations like options disappearing and with no obvious way of getting it back, we have had to open up a Support ticket just to figure out how to get the missing options back
For how long have I used the solution?
I have been using it for around three years.
What do I think about the stability of the solution?
We are about two versions behind. Our upgrades are done by our infrastructure team. We decided that to reduce the amount of work for them that we were going to limit upgrades to approximately every six months, because JAMS does frequently update their software. For the most part, it is fairly stable. We have basically worked out with our infrastructure team to not update every time a new version is released. So, it is done around twice a year.
The product is quite stable and we haven't run into any major issues.
What do I think about the scalability of the solution?
Our infrastructure is pretty straightforward. It is just SQL Server jobs. It works fine on all our Windows machines. We might be exploring a Linux machine for scheduling a SQL Database job, but we haven't done that yet.
The plan is to have all our batch jobs managed by JAMS. For various reasons, mostly related to strange quirks, they weren't able to just migrate every single thing to JAMS, but that is the end goal. We want to have a single scheduling tool that manages all our batch jobs.
We haven't really encountered any scalability issues. Most of our jobs run at night. We have a bunch of daily jobs that run every half an hour. Therefore, it has not been a huge strain on the JAM server.
There are not that many users of JAMS, probably five or six. We have one administrator who is part of our infrastructure team who can configure JAMS etc., but acts in more of an implementer role. He was the one who installed the software. Setting up jobs and things like that is left up to my group. There are two people in my group who have permission to create and submit jobs. Then, we have about three or four inquirers who look at the output of the jobs, but don't have the permissions to submit jobs.
How are customer service and support?
Reach out to their support, because they're support is really good.
I would give HelpSystems IT support a nine out of 10, which is really good. I have been very impressed with their support. The only reason for a nine out of 10 is sometimes it takes at least a day for them to get back to me, which isn't really that big a deal. However, for the most part, if we do it within U.S.A. working hours, then I get a response pretty quickly. Also, after hours, I think I have sometimes gotten their London support.
We have had situations where we would hide things and could never figure out how to actually get things back. We would inadvertently just hide things without even knowing that we hid them, then we literally have to reach out to JAMS support. As far as kudos, JAMS support is excellent. They are very responsive. There have been little things like, "We lost a window. How do we get that back?" The fact that you had to hover over a specific area of the UI, then depending on where you hovered, you could get that particular window pane back. That was the first thing that we ran into, because it was like, "We lost this. How do we get this back?"
Which solution did I use previously and why did I switch?
I actually was the one who brought the product in. My group was looking for a scheduling tool. Until I arrived, everybody was just using the built-in scheduler, which was fine, but it was impossible to look at things practically or even determine dependencies. So, everybody was just using spreadsheets, but I hadn't. The place I came from, which was the private sector, had money. They were using a full-fledged scheduling software, Control-M, which was really expensive. When I came to San Francisco Public Works, they didn't have it. Therefore, I started looking around to see what was available.
Previously, we were using SQL Server Agent. Migrating these has been going well. One of the great advantages of JAMS is it can just convert SQL Server Agent jobs directly, which is not ideal because you are still running SQL Server Agent. This is one reason why we are doing things slowly. We are decomposing the SQL Server Agent jobs into steps and scheduling those, rather than running SQL Server Agent jobs.
How was the initial setup?
The initial setup was pretty straightforward. We just followed the instructions that were on the webpage. So, on the actual JAMS site, there are steps you need to follow if you are installing JAMS. We just followed them and pretty much everything worked.
The deployment took less than an hour. It was pretty quick.
We went from nothing. We just deployed all the new tasks first. So, all of the SSIS jobs that my group had built. These were all new. We didn't really have anything to convert because it was already there. That was the initial phase. That is why it was pretty quick. Once we were comfortable using it, we started to expand the use of JAMS to start converting some of the SQL Server agent jobs into JAMS.
We migrated from an on-prem JAMS to an Azure VM JAMS. So, we actually did a migration, which also involved an upgrade in the process. There was a time when we hadn't upgraded JAMS for over a year, so we were way behind. What we were told by JAMS support is to upgrade our JAMS first, then redeploy it on an Azure VM, and that went without a hitch. I was quite surprised and impressed by how easy it was. Support also said, "If you need us, we can be on the line." We scheduled some time with them, but we never really used them.
We installed the Interactive Agents once. There was an odd case where we were trying to automate a Microsoft Access script or something, which required the Interactive Agent to be installed. This took awhile because of permissions and things like that. Once it was working, it just worked like any other JAMS job. The only hassle was setting it up. We were a bit confused by the documentation. This was at least six months back, but it had something to do with the instructions not being entirely clear as to what types of authentication we had to set up. We reached out to JAMS support, and they said, "Do this." Once we did that, it worked. That was really our only exposure to the Interactive Agents.
What about the implementation team?
We did it all ourselves.
It has been a while since we installed it, but we might have had someone on the line. They actually said, "If you want, we can be on the line." We might have used that, but I don't think we really needed them because it was just click, click, click, and follow the instructions.
We have an infrastructure group, but deployment for JAMS usually defaults to a single person, since he was the one who installed it in the first place. So, he has the most "knowledge" for upgrading patches.
What's my experience with pricing, setup cost, and licensing?
We haven't had the requirement to go beyond our number of licenses. The way that the license is set up, we are allowed a certain number of jobs a day. That is the license that we have, which is more than enough.
It was $10,000 for the first year. Then, there is a maintenance cost for licensing every year that we get billed $5,000 for every year.
The way that the license is set up = it will allow you to 350 jobs a day. You can install the agent on as many machines as you want, but you can only run 350 jobs a day. Then, if you want more, you pay for more.
Which other solutions did I evaluate?
I looked at VisualCron. The reason why I picked JAMS over VisualCron was that JAMS got back to me very quickly. VisualCron took two days. They are a much smaller company and took a couple of days before they got back to me. Because the main thing is really the type of support that I could get, JAMS won out over VisualCron, even though VisualCron ironically looks prettier.
The JAMS client is ugly, but I got support. With VisualCron, which I think is based in Sweden, the time difference would have been difficult, whereas JAMS is somewhere within the U.S.A. In hindsight, it is probably a lot easier to use JAMS because we are the government, so it probably looked better than if I was dealing with someone from overseas.
Before they were bought over by HelpSystems, they were just JAMS. I spent time on quite a few phone calls with their sales rep, who won me over with their level of support.
What other advice do I have?
Biggest lesson learnt: It is critical having a scheduling tool that will show you where all the jobs are and what their dependencies have been when you are doing batch jobs. In the past, SQL Server Agent jobs allowed you to do it, but you really needed the ability to look at interdependencies between jobs. That is what JAMS gives you.
The reason why I am giving it a seven is because of the UI. If they fix the UI, I would give a higher grade than seven.
Which deployment model are you using for this solution?
On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Hi Garth – I wanted to follow-up on your review to let you know our development team is finalizing JAMS v7.5 which will include search capabilities. Be on the lookout for this update coming Fall 2022!