IBM i Glossary

This glossary is the central reference for learning IBM i concepts with AI. Each term is defined in plain English, explained in the context of daily administration, and cross-linked to related concepts, tools, and playbooks.

If you are new to IBM i, start with Learning IBM i with AI for a structured path through the Observe → Recommend → Act model, then return here to deepen your vocabulary.

Work Management

These terms govern how work enters, runs, and exits the system.

Job

A job is a unit of work on IBM i — the equivalent of a process on other platforms. Every interactive session, batch program, and background task runs as a job with a unique qualified name (number/user/name).

Why it matters: Jobs are the primary lens for troubleshooting. When a program hangs, a report fails, or a user session freezes, you diagnose at the job level using job logs, active job lists, and status codes. The platform's Observe → Recommend → Act model centers on job inspection before any state change.

Subsystem

A subsystem is a runtime environment that manages a pool of resources (memory, CPU, storage) for a class of jobs. IBM i ships with subsystem descriptions like QINTER (interactive) and QBATCH (batch). You start, monitor, and stop subsystems independently.

Why it matters: Subsystems isolate workloads. If interactive response time degrades, you inspect QINTER; if batch backups stall, you inspect QBATCH. Misconfigured subsystem routing entries are a common cause of jobs running in the wrong environment.

Job Queue

A job queue is a holding area where jobs wait until a subsystem is ready to run them. Jobs are submitted to a queue (e.g., QBATCH) and are selected by an active subsystem based on priority and availability.

Why it matters: A backed-up job queue is often the first sign of resource contention. Monitoring queue depth tells you whether the system is keeping up with its workload or if jobs are stacking up indefinitely.

Output Queue

An output queue stores spooled output waiting to be printed or processed. When a job generates a report, the output lands on an output queue (often QPRINT) where it waits for a printer writer or digital extraction.

Why it matters: Output queues reveal the health of your print and report infrastructure. Stuck entries may indicate a downed printer, a disabled writer, or a runaway report job.

Message Queue

A message queue is a mailbox for system and program messages. Every user and many system processes have one. QSYSOPR is the operator message queue; QHST is the history log queue.

Why it matters: Messages are IBM i's primary event notification mechanism. Unanswered inquiry messages in operator queues can halt batch streams. Monitoring message queues is a core operator responsibility.

QSYSOPR

QSYSOPR is the system operator message queue — the default destination for critical system messages, hardware alerts, and job inquiries requiring human response.

Why it matters: An unanswered message in QSYSOPR can pause an entire batch cycle or leave a hardware fault unacknowledged. Daily operator playbooks should include a QSYSOPR triage step. See Admin Playbooks for a sample daily health checklist.

AI Tip: Ask the AI to Check QSYSOPR and tell me whether any messages still require attention. This is a safe, read-only Observe action that invokes inspect_messages (view: "qsysopr") and mirrors the first step any senior operator takes.

Storage & Objects

These terms describe how IBM i organizes and persists data on disk.

ASP

An ASP (Auxiliary Storage Pool) is a collection of disk units managed as an independent storage domain. The system ASP (ASP 1) always exists; additional user ASPs isolate data for performance, availability, or organizational reasons. Independent ASPs (IASPs) can be switched between partitions.

Why it matters: ASPs determine where your libraries, journals, and IFS data physically reside. Filling the system ASP to capacity will halt the partition. Monitoring ASP utilization is a foundational health check.

Related: Library · Object · LPAR · Tools: inspect_storage

Library

A library is a container for IBM i objects — analogous to a directory in other filesystems, but strongly typed. Objects inside a library (programs, files, commands) are referenced as LIBRARY/OBJECT.

Why it matters: Library design impacts security, backup scope, and software deployment. Well-designed environments separate production, test, and utility libraries. QGPL (general purpose library) is the default catch-all and often accumulates orphans.

Object

An object is any named entity on IBM i with a specific type. Examples include *PGM (program), *FILE (database or device file), *CMD (command), and *OUTQ (output queue). Every object resides in exactly one library and carries metadata including owner, creation date, and authority.

Why it matters: Understanding object types prevents dangerous mistakes. Restoring a *FILE requires different parameters than restoring a *PGM. Object ownership and authority determine who can execute, read, or delete it.

Source Physical File

A source physical file (type *FILE, attribute PF-SRC) is a specialized database file that stores source code members. Unlike stream files, source physical files use fixed-length records and are the traditional home for RPG, COBOL, and CL source.

Why it matters: Legacy applications and many IBM utilities still expect source in QRPGLESRC, QCLSRC, and similar source files. Modern tools increasingly support stream files, but understanding source physical files is essential for maintaining older codebases.

Related: Object · Library · IFS Stream File

Save File

A save file (type *SAVF) is a repository-in-library used to store saved data temporarily on disk. It is commonly used to stage objects or libraries before FTP transfer, PTF application, or cross-system restore.

Why it matters: Save files bridge backup and transport workflows. Instead of writing directly to tape, administrators often save to a *SAVF, verify contents, and then move the file to its destination.

Spool File

A spool file is a logical output file held in an output queue, typically produced by a print job. Spool files can be printed, converted to PDF, or archived without altering the originating application.

Why it matters: Spool files are the standard output mechanism for IBM i reporting. Administrators manage spool file volume to prevent output queues from consuming excessive storage or blocking printer devices.

Journal

A journal is an object that records changes to database files, allowing recovery, replication, and auditing. Each journaled file has an associated receiver that holds the chronological record of insert, update, and delete operations.

Why it matters: Journaling is required for commitment control, high availability replication, and many modern SQL operations (e.g., avoiding SQL7008 errors). Without journals, recovering a database to a point in time is impossible.

Security

These terms define IBM i's identity and access model.

User Profile

A user profile is the IBM i identity for an individual or service account. It stores the user name, password, default library, initial menu, job description, and a collection of special authorities (e.g., *ALLOBJ, *SECADM).

Why it matters: User profiles are the root of all access. Overprivileged profiles (*ALLOBJ) are a major audit risk. Proper provisioning follows the principle of least privilege: grant only the special authorities and group membership required for the role.

Group Profile

A group profile is a user profile designated to manage authority for multiple members. Instead of granting access to fifty individual users, you grant access to a group and add users as members.

Why it matters: Group profiles simplify administration and audit trails. Changing one group membership updates access for all members instantly. They are the preferred mechanism for role-based security.

Related: User Profile · Authorization List · Authority

Authority

Authority is the broad permission model on IBM i. It encompasses special authorities (system-level powers like *JOBCTL), object authority (access to a specific object), and data authority (read, add, update, delete within a file).

Why it matters: Misconfigured authority is the leading cause of security incidents on IBM i. Understanding the difference between special, object, and data authority lets you diagnose "access denied" errors without reflexively elevating users to *ALLOBJ.

Object Authority

Object authority defines what operations a user or group may perform on a specific object (e.g., *USE, *CHANGE, *ALL). It is stored in the object itself and evaluated at runtime.

Why it matters: Object authority is the gatekeeper. Even if a user has the correct special authority, an object with restricted ownership or a missing authorization can block legitimate work. Auditing object authority is a standard compliance task.

Authorization List

An authorization list is a named collection of users and their authorities that can be attached to multiple objects. Updating the list updates access for every associated object in one operation.

Why it matters: Authorization lists prevent the administrative nightmare of updating hundreds of objects individually. They are the standard tool for managing application-wide security policies.

IFS & Filesystem

These terms cover the Integrated File System, IBM i's unified filesystem that bridges traditional objects and stream-based files.

IFS

The IFS (Integrated File System) is a hierarchical filesystem that unifies multiple file systems under a single directory tree. It includes the traditional QSYS.LIB library structure, the QDLS document library, the QOpenSys POSIX-rooted tree, and user directories under /home.

Why it matters: Modern applications, open-source tools, and PASE utilities all operate through the IFS. The IFS is also the standard path for transferring files to and from IBM i via SFTP, SCP, or REST APIs.

IFS Stream File

An IFS stream file is a byte-stream file stored in the Integrated File System, comparable to files on Linux or Windows. Unlike traditional database files, stream files have no fixed record format and are ideal for JSON, XML, logs, and source code.

Why it matters: Stream files are the primary interface for modern DevOps, open-source languages, and AI-generated artifacts. Understanding the difference between stream files and database files helps you choose the right storage for each integration pattern.

Root Directory

The root directory (/) is the top-level node of the IFS tree. All file systems — including QSYS.LIB — are mounted beneath it. In practice, most user and application data resides under /home, /tmp, or custom mount points.

Why it matters: Navigating the root directory is the starting point for any IFS-based investigation. Permissions at the root level can cascade down the tree, so changes here require caution.

System & Maintenance

These terms cover partition architecture, patches, and transactional integrity.

PTF

A PTF (Program Temporary Fix) is an IBM-provided patch for the operating system or licensed programs. PTFs correct defects, close security vulnerabilities, and occasionally deliver small enhancements.

Why it matters: Keeping PTFs current is a baseline security and stability requirement. IBM publishes PTF cover letters that explain prerequisites, special instructions, and whether an IPL (restart) is required.

PTF Group

PTF groups are bundled collections of related PTFs for a specific product or function (e.g., a cumulative fix pack for Db2 or a security vulnerability bundle). Ordering and applying by group ensures dependency coverage.

Why it matters: Applying individual PTFs without checking the group can leave dependent fixes missing. Modern IBM i maintenance uses group PTFs as the default unit of planning.

Commitment Control

Commitment control is IBM i's transaction integrity mechanism. It ensures that a grouped set of database changes either fully succeeds (commit) or fully rolls back, protecting data from partial failures.

Why it matters: Without commitment control, a job failure mid-transaction can leave tables in an inconsistent state. It is also required for many modern SQL operations and ODBC integrations.

Related: Journal · Object

LPAR

An LPAR (Logical Partition) is a virtualized instance of IBM i running on POWER hardware. A single physical server can host multiple LPARs, each with dedicated or shared CPU, memory, and I/O resources.

Why it matters: LPARs isolate production, test, and development environments on shared hardware. Understanding LPAR boundaries prevents administrators from accidentally running commands on the wrong partition.

How to Use This Glossary with the AI

This glossary is designed to work alongside the AI's Observe → Recommend → Act tools. Use it in three ways:

Learn before you Observe. Read a term's definition, then ask the AI to observe the corresponding system state. Example: after reading about ASP, run Check storage usage summary and tell me whether capacity looks healthy.
Ground your Recommendations. When the AI suggests a plan, return to the glossary to verify what objects, authorities, or queues are involved before approving the action.
Diagnose with vocabulary. Paste an error message or status into the AI, then reference glossary terms to narrow the investigation.

Example Prompt

"I see a lot of jobs stuck in subsystem QBATCH. Use the glossary concepts for Job Queue, Subsystem, and Job to tell me why they might be waiting, then inspect the active jobs and job queues to confirm your hypothesis."

This pattern teaches both the vocabulary and the tooling simultaneously. Return to Learning IBM i with AI for a full curriculum, or view the Admin Playbooks for daily operating procedures.

Last updated: 2026-05-21