If you've spent any time on an AS400 — or IBM i, as it's officially called today — you've probably run the command WRKSBS or WRKACTJOB and seen a bunch of names like QINTER, QBATCH, and QCTL sitting there. Those are subsystems. And if you're new to the platform, that word alone can be confusing, because "subsystem" doesn't map cleanly onto anything in Windows or Linux. So let's break down exactly what a subsystem is, why IBM designed things this way, and why it still matters today.
The simple definition
A subsystem is an operating environment within IBM i where jobs run. Think of it as a container — a dedicated space with its own memory pool, its own set of resources, and its own rules about what kind of work is allowed to run inside it.
Here's the important part: IBM i doesn't run all your jobs in one big shared space. Instead, it divides work into categories, and each category gets its own subsystem. Interactive jobs — the ones where a user is sitting at a 5250 screen typing commands — run in one subsystem. Batch jobs, the background processes that don't need a user watching them, run in another. Communications jobs, like the ones handling TCP/IP or FTP connections, often run in yet another.
Why does this separation exist?
This goes back to how IBM designed the System/38 and later the AS/400 in the first place. The idea was resource control and stability. If interactive users and batch jobs shared the exact same pool of memory and processing priority, a heavy batch job could easily choke out everyone typing on their terminals, and the whole system would feel sluggish for everyone.
By splitting work into subsystems, the system administrator can control exactly how much memory, how many active jobs, and what priority each type of work gets. Interactive users get responsiveness. Batch jobs get the resources they need without stepping on anyone's toes. And if one subsystem has a problem, it typically doesn't take down the entire machine.
The common subsystems you'll see
On a typical IBM i system, you'll usually find:
QCTL – the controlling subsystem. This is usually the first one that starts up, and it manages the console and overall system control.
QINTER – handles interactive jobs, meaning the sessions where users are actively working on 5250 screens.
QBATCH – handles batch jobs, the background processing work like report generation, data transfers, or scheduled jobs.
QCMN or QSYSWRK – handles communications-related work, like TCP/IP jobs, sockets, and various system tasks depending on the OS version.
QSPL – manages spooling, which is how the system handles print output and spooled files.
Many shops also create their own custom subsystems for specific applications, so that a particular piece of software gets its own isolated resource pool, separate from everything else running on the box.
How subsystems relate to jobs and job queues
Here's where it clicks together. When a batch job is submitted, it doesn't go straight into a subsystem. It first lands in a job queue. The subsystem is configured to look at specific job queues and pull work from them, based on rules the administrator has set up — like how many jobs can run at once, and what priority they get.
So the flow looks like this: a job gets submitted, it sits in a job queue, and the subsystem monitoring that job queue picks it up and runs it, provided there's room in the subsystem's active job pool.
This is also why you'll sometimes see a batch job sitting in a queue for a while, not doing anything. It's not stuck — it's just waiting for the subsystem to have available capacity to actually execute it.
Why this still matters in 2026
Even though IBM i has evolved a lot — with support for Java, PHP, open-source tooling, and integration with Linux partitions — the subsystem architecture is still the backbone of how work gets managed on the platform. If you're troubleshooting performance issues, tracking down why a job won't start, or trying to isolate a runaway application, understanding subsystems is often the first place to look.
Commands like WRKSBS, WRKSBSJOB, and WRKACTJOB are your window into this world, letting you see what's running, where, and how busy each subsystem's active job pool actually is.
Once you understand subsystems, a lot of AS400 job management suddenly makes a lot more sense — because almost everything the system does happens inside one.
