What is your primary use case for JAMS?

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.

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.

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.

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.

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

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.

We use JAMS ( /products/jams-reviews ) to replace manual scheduled tasks on our server environment. It serves as a centralized environment to manage scheduled tasks for around 1200 jobs that perform various functions. I'm one of the administrators, and we also use it for smaller tasks on our end as engineers. JAMS ( /products/jams-reviews ) handles SFTP uploads and data copying, among other things.

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.

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.