Library (IBM i)

This article does not cite any sources. Please help by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources:  –  ·  ·  · scholar · JSTOR (December 2009) (Learn how and when to remove this template message)

A library (*LIB) on IBM i is an object that is used as a system directory to keep track of other objects. (It also keeps track of program temporary fixes (PTF) in AS/400 system libraries.) (The other directories that can be used are the directory (*DIR) and folder (*FLR) objects.)

IBM i Objects are not actually stored in libraries. They're really nothing more than namespaces, but it's easier to refer to an object as being "in" or "stored in" a library.

Certain types of object (database file, storage areas and executable program objects) can be compiled, copied, and stored into/from many different libraries concurrently, with the Library List hierarchy determining which instance of the object to use during execution of any application that utilizes that object name. There are Control Language commands to help move objects around, and objects may be qualified at compile time to point to specific other objects statically at runtime, in order to circumvent the Library List.

Other types of objects, designated as "system" objects cannot be replicated. Libraries are a "system" object, and therefore only one instance of any given Library "name" is possible. They're made to appear as if they're stored in the QSYS library. Other "system" objects include user profiles (*USRPRF), configuration objects (*LIND, *CTLD, *DEVD), etc.

Shop Standards[]

On systems with hierarchical filing systems the norm is to have many directories, most of which are contained one within the other, and with a moderate number of files in each directory. Since libraries cannot be stored within other libraries on the AS/400 and because historically the library list was always so small, the opposite became the norm; small numbers of libraries each of which contain large numbers of objects. A library is similar to a folder in Windows. In AS/400 a library is another object that can contain other objects (executable objects, source files, etc.).

Libraries can't contain other libraries. AS/400 is structured as a list, the opposite of Windows which has a tree-like structure.

Most homegrown applications have between one and three libraries. Some have program, source, and file objects together in one library. With shops that have a huge amount of data and a small backup window they usually split the database files into a separate data library and keep the source and programs in another library. In companies with a separate development systems they tend to split it further by placing the source into its own library.

Generally speaking all libraries created by IBM for use by the operating system begin with the letter 'Q'.

IBM Standard Libraries:

• QSYS - System Parent Library
• QSYS2 - System Library for CPI's(Characters Per Inch)
• QHLPSYS - Online Documentation Library for Users
• QTCP - TCP Connectivity Utilities
• QAFP - Advanced Function Printing
• QGPL - General Purpose Library
• QTEMP - Job specific temporary Library (deleted when the job ends)

AS/400 and SQL[]

Most Database management systems (DBMS) use SQL-based terminology to describe objects. The AS/400's terminology is unique and may have generated some confusion. High-level programming languages have often been preferred over SQL with AS/400 programming, due to actual or perceived performance reasons. As SQL programming has become more common on the AS/400, both traditional and SQL-based methods have become available to create and use objects, depending on preference or need. For the most part, traditional library-based objects are the same as SQL objects, with at least equivalent capabilities. For example, a Library is a Schema, a Physical File is a Table, a Logical File is a View, and an Access Path is an Index.

Library List[]

Most systems have a way to find objects when a specific path is not specified. The same is true of the AS/400 and it uses an object called the library list (*LIBL). This object doesn't exist on its own and is always associated with another object like a job or a job description (*JOBD). As of OS/400 V5R1 the user portion of the Library List can contain up to 250 library names. Prior to that it could only have 25 libraries. (This is something to keep in mind when selling software because on OS/400 V4R5 and below a job description with more than 25 libraries in its library list cannot be restored.)

A job's library list consists of four sections:

• System portion: Always at the top and contains system libraries like QSYS, QHLPSYS, QUSRSYS, etc. The system portion can hold up to 15 library names. The default contents of the system portion are specified in the QSYSLIBL system value. The contents of the system portion can be changed for the current job to differ from QSYSLIBL by using the CHGSYSLIBL command.
• Product portion: When a CL command is executed that specifies a production library, that library will be added to the product portion of the library list for the duration of the command. It follows the system portion and the O/S will maintain up to two libraries in it.
• Current library: Is a special library associated with a user profile and there can only be one in the list at a time. This library is useful for programmers to have their personal library at the top of the list regardless of what the user portion is changed to. It can be changed locally using the CHGCURLIB command. To change it for the user on all future jobs use the CHGUSRPRF command.
• User portion: The last part of the library list that contains all of the application libraries. The list is normally assigned to the job from the job description but for batch jobs this can be overridden using the SBMJOB command's INLLIBL parameter. A job's library list can be changed locally with the EDTLIBL(Edit Library List), CHGLIBL(Change Library List), ADDLIBLE(Add Library List Entry), and RMVLIBLE(Remove Library List Entry) command.

As was mentioned above the user portion of the library list for any job can be stored in a job description so that when a job starts up it will use the list specified there. Some job descriptions specify the special value *SYSVAL which means that the library list can be found in the system value QUSRLIBL. IBM i will allow the programmer to delete a library that is in a job description or either of the library list system values provided there are no jobs locking the library. However, all future jobs that use these now tainted lists will fail to start.

External links[]

• AS/400 Library List