Running Linux Commands on AS400: A Look at PASE, QSH, and QP2TERM

Here's something that surprises a lot of people new to IBM i: you don't need to leave your AS400 session to run Unix-style commands. Hidden inside IBM i is a genuine Unix runtime environment — and two different doors into it. This post breaks down what PASE actually is, and how QSH and QP2TERM give you two very different ways to use it.

What Is PASE, Really?

PASE stands for Portable Application Solutions Environment. It's an AIX-compatible runtime that's been built into IBM i since V4R4. In plain terms: IBM i has a genuine 64-bit AIX (Unix) runtime living alongside the traditional OS/400 environment, sharing the same machine, same IFS, same job structure — but running Unix binaries and shell commands natively.

This isn't an emulator and it isn't a translation layer bolted on top. PASE processes run as real jobs on IBM i, with access to the Integrated File System (IFS), and can even call back into traditional IBM i programs (RPG, CL, COBOL) and vice versa. That interoperability is what makes it genuinely useful rather than a novelty.

Two Doors Into PASE: QSH vs QP2TERM

This is where people usually get confused, because QSH and QP2TERM feel similar on the surface but serve different purposes.

QSH (Qshell)

Qshell is a POSIX-compliant shell environment that runs on IBM i. You start it by running the QSH command (or STRQSH) from a 5250 command line.

STRQSH

Once inside, you get a Unix-like shell (based on the Korn shell) with access to a large set of Qshell utilities — commands like ls, cp, mv, grep, find, chmod, and more, implemented specifically for IBM i's environment. Qshell is commonly used for:

• Scripting IFS file operations
• Running Java-based utilities and JVM apps
• Text processing (grep, sed-like operations) against IFS files
• Scheduled batch jobs that need Unix-style scripting logic

Qshell commands are IBM i-native implementations that mimic Unix behavior — they're not the actual AIX binaries. This matters for compatibility: Qshell covers common cases well, but it isn't a full AIX environment.

QP2TERM

QP2TERM is different — it's an actual interactive PASE terminal session. You launch it with:

CALL QP2TERM

This drops you into a genuine AIX shell (ksh) running inside your 5250 session, with access to real PASE/AIX utilities and binaries — not IBM i's Qshell reimplementations. This is the closer-to-"real Linux/Unix" experience of the two.

Inside QP2TERM you can run standard AIX commands, navigate the IFS as a Unix filesystem, and execute PASE-compiled programs (including some open-source tools that have been ported to PASE, like OpenSSH, Python, Node.js, and others via the IBM i Open Source Package Management, formerly known as the "Yum for IBM i" ecosystem).

Quick Comparison

	QSH (Qshell)	QP2TERM
Command	STRQSH	CALL QP2TERM
Shell type	POSIX shell (IBM i-native implementation)	Real AIX Korn shell (ksh)
Commands available	Qshell utilities (IBM i reimplementations)	Actual PASE/AIX binaries
Best for	Scripting, batch jobs, IFS file ops	Interactive Unix-style admin work, running ported open-source tools
Feels like	A Unix-flavored IBM i shell	An actual Unix terminal

Why This Matters If You're Learning Linux

If you're an IBM i admin dipping into Linux, QP2TERM is genuinely useful low-stakes practice ground. You get to run real ls, grep, ps, and other Unix commands, on hardware you already have access to, without spinning up a separate VM. It won't replace learning on a real Linux box — PASE is AIX-flavored Unix, not Linux, and there are behavioral differences — but the muscle memory for command syntax, flags, and piping transfers directly.

It's also worth knowing this exists for the reverse reason: if you ever need to run open-source tooling (OpenSSH, Git, Python, Node.js) on your IBM i system itself, PASE is the mechanism that makes that possible. IBM's Open Source Package Management for IBM i is built on top of this same PASE runtime.

Try It Yourself

If you have access to an IBM i system (pub400.com works fine for this):

CALL QP2TERM

Once inside, try:

pwd
ls -la /home
ps -ef | more

Then exit with:

exit

...which drops you back to your 5250 command line, right where you left off.

An IBM i Admin's Guide to Linux: Terminal Basics

If you've spent years on the green screen — running WRKOBJ, WRKLIB, WRKACTJOB without a second thought — Linux's command line will feel more familiar than you'd expect. It's not a different universe. It's a different dialect of the same language: tell the system exactly what you want, and it does it.

This post kicks off a new series where we translate IBM i / AS/400 concepts into their Linux equivalents. If you already think like a sysadmin, you're closer to "Linux admin" than you think.

The Mental Model Shift

On IBM i, almost everything runs through menus, commands with prompts (F4 is your best friend), and object-based navigation. Linux drops the menus and prompts — you type the full command up front. That's the biggest adjustment: less hand-holding, more precision.

But the underlying logic is the same: you're still navigating a hierarchy of "objects" (files, directories, jobs) and asking the system to list, inspect, move, or act on them.

Core Command Translations

What you want to do	IBM i	Linux
See what's in a library/directory	WRKLIB / WRKOBJ	ls
Change current library/directory	CHGCURLIB	cd
Show current location	(implied by session)	pwd
Display file contents	DSPPFM	cat, less, more
Copy a file/object	CPYF	cp
Move/rename an object	RNMOBJ	mv
Delete an object	DLTF / DLTOBJ	rm
Create a directory/library	CRTLIB	mkdir

A few notes on the mapping:

• ls is your WRKOBJ. Add flags to get more detail — ls -l gives you a long listing (permissions, owner, size, date), which is roughly the level of detail you'd get from an object's attributes in WRKOBJ with F11.
• cd has no F4 prompt. You need to know the path already, or use ls first to see where you can go. There's no visual menu — that's the trade-off for speed.
• Everything is case-sensitive. MyFile.txt and myfile.txt are two different files on Linux. This trips up a lot of IBM i folks at first, since object names are traditionally uppercase and case-insensitive.

Try It Yourself

You don't need to buy anything to practice this — just like pub400.com gives you a free sandbox for AS/400, you have free options for Linux too (I'll cover these in an upcoming video):

• WSL2 if you're on Windows — a real Linux environment inside Windows, no VM needed
• A free-tier cloud VM (Oracle Cloud and a few others offer always-free tiers)
• VirtualBox with a lightweight Ubuntu Server ISO

Once you're in, try this five-minute exercise:

pwd                 # see where you are
ls -l                # list contents with detail
mkdir test_dir       # create a directory
cd test_dir          # move into it
cat > notes.txt      # create a file (Ctrl+D to save and exit)
ls -l                # confirm it's there
cat notes.txt        # view the contents

If that felt intuitive, you're already thinking like a Linux admin — you just need the vocabulary.

What's Next

Next up in this series: File Systems Compared — IFS vs the Linux Filesystem Hierarchy, where we'll map out /QSYS.LIB, /home, and everything in between.

If you're an IBM i person dipping a toe into Linux, drop a comment with what trips you up most — that'll shape where this series goes next.

What Is a Library List in IBM i (AS400)?

If you've spent any time on an IBM i (AS/400) system, you've probably typed a command like WRKOBJ or called a program without specifying a library, and it just... worked. No QGPL/MYPGM, no full path — just MYPGM. That's the library list at work.

For anyone coming from a Windows or Unix background, this concept can feel unfamiliar at first. There's no single "current directory" the way you'd expect from a PC. Instead, IBM i uses a library list (*LIBL) — an ordered list of libraries that the system searches, in sequence, whenever you reference an object without qualifying it by library.

The Basic Idea

Every object on IBM i — a program, file, data area, whatever — lives inside a library. Libraries are themselves just a special type of object (*LIB) that hold other objects.

When you run a command or call a program without telling the system exactly which library to look in, IBM i doesn't guess randomly. It walks through your job's library list, library by library, in a fixed order, and uses the first matching object it finds.

You can see your current library list at any time with:

DSPLIBL

or interactively manage it with:

WRKLIBL

The Four Parts of a Library List

A job's library list isn't just one flat list — it's built from four distinct portions, always searched in this order:

1. System portion — Libraries IBM i itself needs, most importantly QSYS, which holds core OS objects. This portion is controlled by the system value QSYSLIBL and can't be changed per-job.
2. Product libraries — Reserved for licensed program products. Rarely touched manually.
3. Current library — A single library tied to your job, typically set by your user profile or job description (CURLIB parameter). This is where the system looks for objects you create without specifying a library, and it's often the first place developers check.
4. User portion — A list of up to 25 libraries that you or your job description define, searched in the order they were added. This is what most people mean when they casually say "my library list."

How Libraries Get Added

The user portion of the library list is usually built in one of these ways:

• Job description (INLLIBL parameter) — sets the initial user library list when the job starts
• ADDLIBLE — adds a library to your current job's library list
• RMVLIBLE — removes one
• CHGLIBL — replaces the entire user portion in one shot
• EDTLIBL — lets you interactively edit it

These changes only affect the job you're running in — they don't touch anyone else's session or the system-wide defaults, unless you're changing a job description that other jobs are built from.

Answering the Real Question: If the Same Object Exists in Multiple Libraries, How Does IBM i Know Which One to Use?

This is the part that trips people up the most, and it's genuinely the whole point of the library list.

Say you have a file called CUSTMAST sitting in three different libraries: PRODLIB, TESTLIB, and MYLIB. If your program or command references CUSTMAST without qualifying it (i.e., you don't write PRODLIB/CUSTMAST), IBM i resolves it like this:

1. It starts at the top of your library list — system libraries first, then product libraries, then your current library, then your user library list, in that exact order.
2. It checks each library one at a time, asking "does this library contain an object named CUSTMAST of the type I'm looking for?"
3. The very first match it finds wins. IBM i stops searching immediately — it does not check the remaining libraries, and it does not care whether a "better" or more recent copy of CUSTMAST exists further down the list.

So the answer, in short: IBM i doesn't pick the "right" copy — it picks the first copy it finds, based purely on the order of libraries in your library list. There's no timestamp comparison, no size comparison, no ownership logic. It's pure sequential search, top to bottom.

This has a very practical consequence: if TESTLIB happens to sit higher in your library list than PRODLIB, and both contain CUSTMAST, your program will silently pick up the test version — with zero warning that it did so. This is one of the most common (and most dangerous) sources of "it worked on my machine" bugs on IBM i. A developer tests against their own TESTLIB copy, everything looks fine, but in production the library list order is different and an entirely different object gets used.

Bypassing the Search Entirely

Of course, you can always sidestep the whole library list mechanism by fully qualifying the object:

PRODLIB/CUSTMAST

When you specify the library explicitly, IBM i doesn't search anything — it goes straight to that library. This is the safest approach for production programs, and it's why well-written IBM i applications tend to hard-code library qualification (or use library list conventions very deliberately) rather than relying on implicit resolution wherever correctness matters.

Why This Design Exists

It might seem odd at first, but the library list system is actually a clever piece of environment management. It lets the same program name, called the same way, resolve to different actual objects depending on context — without changing a single line of code:

• A developer's library list might put DEVLIB first, so ADDLIBLE picks up their in-progress work.
• A tester's library list might put TESTLIB first.
• Production jobs are typically configured (via job description) to see only PRODLIB, with no dev or test libraries anywhere on the list.

This is essentially IBM i's built-in mechanism for environment switching — no separate deployment paths, no changing file references in code, just a different library list per job.

Quick Reference

Command	Purpose
DSPLIBL	Display your current library list
WRKLIBL	Work with (interactively manage) your library list
ADDLIBLE	Add a library to the user portion
RMVLIBLE	Remove a library from the user portion
CHGLIBL	Replace the entire user portion
EDTLIBL	Interactively edit the user portion

The Takeaway

A library list is IBM i's answer to a question every multi-user, multi-environment system has to solve: when a name could mean several things, which one do you mean? IBM i's answer is refreshingly simple once you see it — a strict, ordered search, first match wins. Understanding that order (system, product, current library, user list) — and knowing that duplicate object names anywhere along that path are resolved by position, not by "correctness" — is one of the most important mental models you can build as an IBM i developer or operator.

What Is a Subsystem in AS400 (IBM i)?

 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.