What is your primary use case for JAMS?

We use Fortra's JAMS to schedule jobs.

We use JAMS for managed file transfer and job scheduling Fortra's diverse enterprise application. The managed file transfer is both internal and with external third-party vendors.

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

I've used the solution across three employers. I've used it in the context of government, tech services and health care. Everything is IT-related, so everything from ordering supplies to finance applications, everything gets filtered through JAMS. It helps with automation.

We use Fortra's JAMS as a job scheduling tool for state agencies across the country. We primarily use it for scheduling jobs and development tasks related to taxation processes.

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

We implement Fortra's JAMS for our clients, utilizing their existing scripts, batch jobs, and stored procedures. We define all batch jobs within JAMS, providing our clients with a single console to monitor and track the status of their running jobs.

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

We 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.

We use JAMS to run various tasks, such as nightly claims processing jobs. It's also helpful for moving files around and interfacing between the cloud and our on-prem systems. The company has 50 to 100 users, including admins, developers, and on-call maintenance staff. We also have reporting staff who monitor jobs to see if they are succeeding.

I use JAMS to run repetitive tasks that I need to do each day, like loading database entries, performing backups, and building daily reports. The organization uses it for complex workflows, sequences, and ad hoc jobs. We aren't using JAMS for much complex scheduling. We schedule tasks on weekdays, but we aren't using a calendar to specify holidays. That is something on the to-do list. We want to have it scheduled to run on the work week except for holidays or other exceptions. However, it can run jobs based on sets of schedules and sequences.

We have batch processes that run either on-demand or on a scheduled basis. JAMS is used to manage and run those jobs.

We run thousands of tasks for various purposes, including data manipulation, human resources, data flow, data management, and scripting. We use the solution for any task involving data management that must be scheduled.

We used it for scheduling our jobs. Our jobs were set up on different servers, which made the maintenance very difficult, and the main reason we switched over to JAMS was that we could have all our jobs from different servers in one single place. Secondly, we had many workflows that had to be triggered automatically, and JAMS was pretty much the tool that we wanted. We found it very useful to do workflow scheduling.

We have a student information system (SIS) for education. We have 50 school districts that run on the same database, and they all can run reports through the GUI. JAMS manages the reports. We have a throttle so that they don't overpower the system. So, the stuff comes through the system and the throttle manages it, and then if there's a certain report that runs over, we can kill it. They can run it again with better parameters. That's pretty much the main use. We have a lot of nighttime jobs that we schedule through that as well. It's deployed on our private cloud. We run our own server. In terms of its version, we're on the most recent version.

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.

We started with basic tasks because we were bringing things over from Windows Task Scheduler. We didn't have a whole lot of dependencies at that point. We have gotten much more detailed in our scheduling requirements since. We use what are currently called JAMS Setups, which in the new version are called Sequence Jobs, quite a bit, especially for our enterprise data analytics team. We do some pretty complex scheduling scenarios. We also use it for holiday calendars that impact our scheduling and for multiple regular scenarios, such as dependencies on a file or another job or another Setup. Overall, we use it for basic, normal enterprise-scheduling solutions.

The initial use case is that we use it to centralize everything, including all jobs from across different environments. Our goal is to be able to do all of the maintenance centrally. When our jobs run, our team handles the jobs and they are not assigned to other teams. The output, which is on the backend and put into the database, is available for everyone.

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.