JAMS Software is pitching IBM i shops on a familiar operational problem: batch jobs may still run on IBM i, but the workflows they support increasingly span Windows, Linux, databases, cloud services, file transfers, and business applications. In a sponsored article published by IT Jungle, JAMS solutions engineer Rob Newman argued that scheduling those pieces separately leaves teams without a reliable view of dependencies or failures.
The central message is not a new IBM i feature or product release. It is a workload-automation pitch aimed at organizations where IBM i processes feed, or depend on, Windows-hosted applications, SQL Server databases, reporting platforms, ERP software, and custom scripts.
Newman describes a typical chain in which an incoming SFTP file starts an IBM i task, followed by database updates, BI reporting, and ERP processing. The issue, he says, is that each part is often scheduled independently. When a midstream job fails, operators may need to identify what ran, what did not, and whether downstream systems consumed incomplete data.
JAMS positions its scheduler as a central console for IBM i, Windows, Linux, PowerShell, APIs, and application-specific workloads. The product’s workflow model allows administrators to define success-based dependencies, parallel tasks, notifications, and restart points rather than restarting an entire overnight batch after a single failed step.
For Windows administrators, the practical angle is visibility. A Windows script or SQL Server-related process that is currently managed through Task Scheduler, a manually triggered script, or another scheduler could become part of the same monitored workflow as the IBM i job that supplies its input.
The company also emphasizes that existing CL scripts, RPG-related processes, and custom applications do not need to be rewritten if they can be launched through a command line or programmatic interface. That is important for long-lived IBM i estates where critical process knowledge may be embedded in scripts and legacy applications rather than formal workflow documentation.
Organizations evaluating JAMS or comparable workload-automation tools should inventory cross-platform handoffs first, then test alerting, restart behavior, credential handling, audit logs, and failure recovery against a critical production workflow.
The immediate next step for affected IT teams is to map where IBM i batch processing depends on Windows, Linux, files, APIs, and downstream reporting before the next failed overnight run exposes those links.
The central message is not a new IBM i feature or product release. It is a workload-automation pitch aimed at organizations where IBM i processes feed, or depend on, Windows-hosted applications, SQL Server databases, reporting platforms, ERP software, and custom scripts.
One workflow across mixed systems
Newman describes a typical chain in which an incoming SFTP file starts an IBM i task, followed by database updates, BI reporting, and ERP processing. The issue, he says, is that each part is often scheduled independently. When a midstream job fails, operators may need to identify what ran, what did not, and whether downstream systems consumed incomplete data.JAMS positions its scheduler as a central console for IBM i, Windows, Linux, PowerShell, APIs, and application-specific workloads. The product’s workflow model allows administrators to define success-based dependencies, parallel tasks, notifications, and restart points rather than restarting an entire overnight batch after a single failed step.
For Windows administrators, the practical angle is visibility. A Windows script or SQL Server-related process that is currently managed through Task Scheduler, a manually triggered script, or another scheduler could become part of the same monitored workflow as the IBM i job that supplies its input.
IBM i agent and Windows server requirements
According to Newman, JAMS uses an IBM i agent that runs as a native subsystem and submits work using standard IBM i job-submission mechanisms. The central JAMS Scheduler runs on Windows Server. He also said an x86 server with 16 CPU cores, 64GB of memory, and 1TB of storage can support workloads of up to 100,000 jobs per day, though actual sizing will depend on job types, retention requirements, integrations, and high-availability design.The company also emphasizes that existing CL scripts, RPG-related processes, and custom applications do not need to be rewritten if they can be launched through a command line or programmatic interface. That is important for long-lived IBM i estates where critical process knowledge may be embedded in scripts and legacy applications rather than formal workflow documentation.
A vendor pitch, but a real operational issue
The IT Jungle piece is sponsored content, so its adoption, scale, and pricing claims should be treated as vendor assertions rather than independent market findings. Still, the underlying problem is concrete: a scheduler confined to one platform does not provide end-to-end recovery or dependency management for a process distributed across several systems.Organizations evaluating JAMS or comparable workload-automation tools should inventory cross-platform handoffs first, then test alerting, restart behavior, credential handling, audit logs, and failure recovery against a critical production workflow.
The immediate next step for affected IT teams is to map where IBM i batch processing depends on Windows, Linux, files, APIs, and downstream reporting before the next failed overnight run exposes those links.
References
- Primary source: IT Jungle
Published: 2026-07-13T04:04:53+00:00
Your IBM i Jobs Don’t Live On An Island Anymore - IT Jungle
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...www.itjungle.com