IBM i for a Linux/Windows agent: objects and libraries instead of files and paths

What it is

IBM i (formerly OS/400, running on Power hardware, versions 7.4/7.5/7.6) has no native concept of a Unix-style file hierarchy at its core. Everything the system manages — programs, database physical and logical files, data areas, user profiles, job descriptions — is a typed object, identified by a name of up to 10 characters, an object type (*PGM, *FILE, *USRPRF, and so on), and the library that contains it. A library is itself an object of type *LIB; it is a flat container, not a directory, and cannot nest other libraries (all libraries are objects in the special library QSYS).

Where a Linux process resolves a bare command name through $PATH, an IBM i job resolves a bare object name through its library list (*LIBL): an ordered list of libraries made up of a system portion (up to 15 libraries, including QSYS), optional product libraries, the job's current library (*CURLIB), and a user portion. Any unqualified reference such as MYPGM (commands like DSPLIB are themselves *CMD objects resolved the same way) searches the job's library list unless the name is qualified as LIBRARY/OBJECT. Two jobs with different library lists can call the same unqualified MYPGM and run different programs — the IBM i equivalent of a $PATH shadowing bug; a qualified MYLIB/MYPGM is not affected.

Command names usually follow a pattern: a three-letter verb abbreviation plus one or more noun abbreviations, for example CRTLIB (Create Library), DLTLIB (Delete Library), DSPLIB (Display Library), WRKACTJOB (Work with Active Jobs). Once an agent has decoded a handful of verbs (CRT, DLT, DSP, WRK, CHG, STR, END) and nouns (LIB, OBJ, JOB, USRPRF), most command names become guessable rather than memorized.

For file-oriented tools, the Integrated File System (IFS) exposes the whole object space under /QSYS.LIB/LIBRARY.LIB/OBJECT.TYPE, for example /QSYS.LIB/QGPL.LIB/MYPGM.PGM. This lets a find or ls from a PASE shell see traditional objects, but the cited IBM Support page describes QSYS.LIB as primarily a file system for database files and other library objects, not a general-purpose stream file system: stream I/O works only on a few object types (such as physical file members and save files), and many operations common on / or /home are not supported there.

Why it matters

An agent that treats IBM i as "Linux with unusual commands" will misdiagnose "file not found" errors that are really library-list problems, and will try filesystem operations against QSYS.LIB that the object model does not support.

How to apply

• Before searching for an object, ask which library list applies to the current job, not just what the object is named.
• Read LIBRARY/OBJECT qualification the way you would read an absolute path; treat unqualified names as *LIBL-relative.
• Decode unfamiliar CL command names as verb+noun before assuming an undocumented feature.
• Avoid IFS stream operations (rename in place, arbitrary byte writes) inside /QSYS.LIB; use CL commands (CRT*, CPY*, DLT*) for object lifecycle instead.

Pitfalls

• Assuming a library is a directory that can contain sub-libraries; it cannot.
• Assuming *LIBL is something the agent's shell controls like $PATH; it is a per-job attribute, initialised from the job description or the QSYSLIBL/QUSRLIBL system values and changed with CHGLIBL/ADDLIBLE, so a separate job (for example a submitted batch job) may see a different list.