Objects & library lists

A library is a *LIB object that provides a namespace for library-based objects. It is not a general nested directory tree. IFS directories provide that hierarchical model. Database schemas and libraries are closely related on IBM i, though their creation defaults and contained objects can differ.

Use qualified object names when identity matters. APP/ORDERS describes a library object, while /app/orders is an IFS path. Do not interchange these forms without using the appropriate interface.

The library list provides ordered search locations for supported unqualified object references. It has system, product when applicable, current-library, and user portions. Resolution depends on the interface and requested object type.

When development and production have objects with identical names, the resolved object may differ by job. Display the actual job library list and compare the chosen object. A successful unqualified call does not establish that the intended version ran.

Example

DSPLIBL
DSPPGM PGM(APP/POSTORD)

Interview pitfall: SQL naming and schema settings need separate attention; do not assume every SQL name uses *LIBL.

Each job has its own QTEMP library. Objects created there are isolated from objects of the same name in another job and disappear when the job ends. It is useful for scratch tables and work files that should not survive a run.

It is unsuitable for a durable restart checkpoint or direct sharing between producer and consumer jobs. Long-lived server jobs can retain QTEMP state across requests, so explicitly initialize or clear request-specific data.

Example

Two jobs can each create QTEMP/WORK without sharing its rows.

Capture the message identifier and fully qualified object type/name being sought. Check that the object exists in the expected library, then inspect the failing job environment, including its library list, current library, SQL naming settings, and overrides where relevant.

Compare execution under the same user and job attributes. Also inspect authority and dependent objects; an error about a missing dependency may be misread as failure to find the top-level program. Avoid fixing discovery by adding every library globally.

Explicit qualification makes environment-sensitive dependencies unambiguous, especially for administrative operations and shared infrastructure. Unqualified references can support controlled library-list-based deployment, provided entry points initialize and validate the environment.

Choose a consistent policy rather than scattering production library names through business logic. One useful pattern is an environment-specific wrapper that establishes approved libraries, followed by reusable business procedures with stable contracts. Test both interactive and submitted jobs.

Yes, object identity includes type. A library can contain objects with the same name but different object types. However, different database file attributes such as PF and LF still use *FILE, so that distinction does not permit two *FILE objects with the same name in one library.

When writing tooling, retain type along with library and name. A cleanup script that assumes a name uniquely identifies every object can operate on the wrong target.

Example

APP/ORDERS *PGM and APP/ORDERS *FILE can coexist.

Interview pitfall: PF and LF are attributes, not separate object types for this naming rule.

IBM i supports SQL and system naming conventions, with differences in qualified-name syntax and unqualified-name resolution. SQL naming uses schema.table notation; system naming commonly supports library/file notation and library-list-oriented behavior. Other settings such as current schema and SQL path also matter.

Confirm the connection or precompile naming option and the actual statement context. Do not assume the same unqualified query in ACS and embedded SQL reaches the same table. Qualify critical references or establish a documented environment contract.