Your IBM i Jobs Don’t Live On An Island Anymore

July 13, 2026 Rob Newman

When I am on a call with a prospective customer, one of the first questions I ask is: Are you looking to schedule and automate IBM i jobs specifically, or do you need to incorporate all of your cross-platform dependencies? That question tends to land with a thud. Not because people don’t understand it, but because often they have never really thought about it that way.

They have been running their IBM i jobs the way they always have, and somewhere else in the building, someone else is running Windows jobs a different way, and maybe a Linux process a third way. Nobody has tied them together. And when something breaks, nobody knows where to look.

That is the problem JAMS was built to solve. And honestly, it is a bigger problem than most IBM i shops realize they have.

The Mixed Shop Is The Rule, Not The Exception

Here is a number that might surprise you: Fewer than 5 percent of IBM i shops are IBM i only. The rest are running Windows servers as application or database servers alongside the system, or Linux, or both. Many are running JD Edwards, SAP, Informatica, Oracle – plus their own homegrown RPG applications that nobody outside of two or three people fully understands anymore. They are mixed shops by definition. They just don’t always act that way when it comes to automation.

What I see a lot is siloed thinking. The IBM i side gets scheduled one way. The Windows side gets scheduled another way, or maybe not scheduled at all – someone is running scripts by hand, or poking at it and hoping. And the dependencies between those worlds go unmanaged. A file comes in over SFTP. That triggers an IBM i job. That job kicks off a database update to both Db2 for i and Microsoft SQL Server. That update to SQL Server drives a BI reporting process. All of those steps are connected, but nobody has drawn that map, and nobody is watching the whole picture.

Until something fails. Then you find out how connected everything really is.

What Orchestration Actually Looks Like

JAMS scheduler gives you a single pane of glass across your entire infrastructure. Not just your IBM i jobs –everything. Windows jobs, Linux jobs, PowerShell scripts, API calls to cloud services, JDE processes, Informatica pipelines. Whatever. You can see what is running, how long it has been running, how long it is expected to run, and what has failed. And you have full control: You can cancel a job, hold it, release it, retry it, right from that same console.

The workflow model is where this gets practical. Take that file ingest example I mentioned above. With JAMS, you build out the whole process end to end: The file arrives, it triggers transformation, transformation feeds the database loads, the database loads trigger the extracts, the extracts go to BI, BI generates the reports, and in parallel, that same data gets pushed to your ERP system. Every one of those steps has dependencies on the steps before it. Some can run in parallel; others have to wait. JAMS enforces all of that automatically. Subsequent steps won’t fire until the steps they depend on complete successfully.

And when something does fail – because things fail, that’s reality – you don’t have to restart from the beginning. You fix the step that broke. You retry just that step, or skip past it if you need to, and let the rest of the workflow continue. That is not a small thing. Restarting an entire overnight batch because one step in the middle failed is expensive. Being able to surgically fix the problem and resume the job is a completely different experience.

For alerts, JAMS integrates with whatever your team already uses – email, Slack, whatever. When something goes sideways at 2 a.m., the right person gets notified immediately, and with enough context to understand where in the workflow the problem occurred.

This Isn’t Just For The Big Shops

When I tell people that JAMS scheduler works for shops running one server, I sometimes get skeptical looks. There is an assumption that orchestration tooling is an enterprise thing, that it is built for companies running hundreds of servers with large IT teams. That’s not how we think about it. I would estimate that more than 60 percent of our customer base is running fewer than ten servers. We have customers at one end running on a dual-socket Windows box. We have customers at the other end managing hundreds of servers. The tool scales up and down for both scenarios, and all the ones in between.

How many servers you have doesn’t matter. What matters is how critical your jobs are and how complex your application workflows are. And if you are an IBM i shop, the answer to the question “How complex are your jobs” is almost certainly very complex. Even if those jobs reside inside one or a few machines. These are mission-critical workloads. This is the system running the business. When a job fails on an IBM i platform, it is not an inconvenience, it is revenue at risk.

The pricing for JAMS reflects this reality. We are agent-based, not consumption-based. You are not paying per job run or worrying about overage charges if your workload spikes. You pay based on how many machines you need JAMS to talk to. If that is one machine, the price is one machine. If you grow to five or ten, you grow with it. You want to run five thousand jobs on a single agent? Go ahead – it will handle it, and you won’t get a surprise bill.

What About All Those Custom Applications?

One thing I have learned from working with IBM i customers is that the word “application” covers a lot of ground. A lot of shops are running code they wrote themselves – RPG applications, heavily modified ERP source that the original vendor hasn’t touched in fifteen years, business logic that lives in the heads of two people and a pile of CL scripts. This isn’t the exception. It is closer to the rule.

JAMS can work with all of it. If there’s a command line interface, a programmatic hook, a .NET or Java integration point, then we can build the bridge to it. And if you already have scripts doing this work, even better. That’s actually one of my favorite things to tell people: If you can script it, we can run it. Bring us your scripts exactly as they are. Drop them in JAMS. They will run exactly as they do today, except now they are visible, monitored, and part of your orchestrated workflow instead of sitting in a folder somewhere that only one person knows about.

On the IBM i itself, JAMS installs an agent – a subsystem that runs natively – and connects via FTP to submit jobs through the standard SBMJOB function. We do not try to reinvent how IBM i works. It plugs into the way IBM i works and adds the visibility and dependency management that has been missing. The JAMS Scheduler runs on a Windows Server platform, and if you are handling 100,000 jobs a day, an X86 server with 16 cores running at 3.2 GHz with a mere 64 GB of memory and 1 TB of disk will handle those jobs.

Getting Started Is Easier Than You Think

I’ll be direct: A lot of IBM i shops have convinced themselves that their situation is too unique, too complicated, or too entrenched to change. They have hundreds of scripts, maybe thousands, and the institutional knowledge for how they all fit together is concentrated in one or two people. That’s exactly the kind of situation JAMS was designed for – and ironically, it is exactly the kind of situation where getting started is most valuable.

Installation is straightforward. Getting the application up and running is fast. And from there, we don’t just hand you a manual and wish you luck. I will come in and work with you directly to build out some of your jobs in the environment, starting with your most critical processes. We get them running under JAMS, and in that process you will learn more about how the tool works than you would from any documentation.

Beyond that, we have professional services that can take you end to end, helping you build out your complete workflow structure, give people formal training, the works. The goal is that by the time we are done, your team understands JAMS and your application workflow and they own it and are not dependent on us to run it. That’s the point.

The Real Cost Of Not Having A Scheduler

I think about what it costs when jobs fail without proper orchestration in place. A job fails at 3 a.m. Nobody knows until someone shows up in the morning and something is obviously wrong. Then you spend hours figuring out which step failed, why, what downstream processes didn’t run, what data is incomplete or wrong. That’s downtime. That’s potentially bad data flowing through the business. That’s revenue you didn’t process, reports that didn’t run, shipments that didn’t go out.

With JAMS, that scenario looks different. The job fails, and within minutes the right person is notified with a clear picture of what happened and where. They log in, see exactly where in the workflow things stopped, fix the problem, and restart from that point. The rest of the workflow resumes. The damage is contained.

I have been having this conversation with IT people for years, and the thing I keep coming back to is this: Your IBM i jobs don’t live on an island. They never really did – there were always dependencies, always other systems involved. The difference now is that those dependencies are more complex, the other systems are more numerous, and the business tolerance for failure is lower than ever. The question isn’t whether you need to manage those dependencies. The question is whether you are going to manage them deliberately, with the right tools, or keep managing them accidentally, one crisis at a time.

We all know what the right answer to that question is.

One Scheduler. IBM i, Windows, Linux, and more. See it in action.

Rob Newman is a solutions engineer at JAMS Software, bringing decades of experience specializing in infrastructure support and systems integration across both small and large organizations. He is a technical lead professional providing customer-centric technical demonstrations, custom designed solutions and proof-of-concept installations. His technical expertise, problem solving and strong communication skills guides customers through the seamless integration of workload automation across hybrid IT environments with the goal of building a strategic partnership.

This content was sponsored by JAMS Software.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search