Jobs, Queues, and Subsystems: How IBM i Actually Runs Your Code

Every program that runs on IBM i — whether it's a user signing in interactively, a batch report kicked off overnight, or a system task doing internal housekeeping — runs inside something called a job. Understanding the job model is one of those foundational pieces of platform knowledge that separates developers who can troubleshoot production issues quickly from those who are left guessing.

A job on IBM i is a unit of work that the system tracks from start to finish, and it's a broader concept than a simple process on Windows or Linux. Every job carries its own environment: its own library list, its own job attributes, its own message queue for logging and communication. When something goes wrong in production, the job is usually where the answer lives.

Jobs don't run in isolation. They run inside subsystems, which are operating environments that IBM i uses to control how and where work executes. A subsystem defines things like how many jobs can run concurrently, what storage pools they draw from, and what kind of work it's designed to handle. Most shops run several subsystems simultaneously — one for interactive work, one or more for batch processing, and others dedicated to specific applications or communications work.

Before a batch job actually starts running, it typically waits in a job queue — essentially a holding area where submitted work sits until the subsystem has capacity to run it. This is why a batch job doesn't always start the instant it's submitted, and why job queue priority matters in shops running heavy overnight processing.

IBM i generally recognizes three broad categories of jobs. Interactive jobs are tied to a user actively working at a 5250 session. Batch jobs run without any user interaction, processing in the background — think end-of-day reports, data extracts, or scheduled maintenance. System jobs handle the operating system's own internal work and aren't something application developers typically interact with directly.

The practical payoff of understanding this model shows up the first time you're troubleshooting a slow or stuck process. Is the job stuck in a queue waiting for subsystem capacity? Is it running but blocked on a resource? Is it even the job you think it is? Commands like WRKACTJOB and DSPJOB become far more useful once you understand what they're actually showing you — a snapshot of work moving through subsystems and queues, not just an arbitrary list of numbers on a screen.

This lesson is Lesson 2 of IBM i Platform Foundations in IBM i ILE RPG Mastery, part of a structured foundation designed to make the platform's behavior predictable rather than mysterious before moving into modern ILE RPG development.