AS/400 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 it's own and is always associated with another object like a job or a job description (*JOBD). As of V5Rx 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 V4R5 and below will barf if the user tries to restore a job description with more than 25 libraries in its library list.)

A job's library list consists of four sections:

• System portion: Always at the top and contains libraries like QSYS, QHLPSYS, QUSRSYS, etc. The system portion can hold up to 15 library names and is specified in the QSYSLIBL system value. It can be changed locally using the CHGSYSLIBL command.
• Product portion: When a 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 and there is only one. This library is most useful for programmers to have their personal library at the top of the list regardless of what 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, CHGLIBL, ADDLIBLE, and RMVLIBLE commands.

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. Please note that if library is deleted that is also specified in a job description or either of the library list system values the system will let allow it and all future jobs that use these now tainted lists will fail to start

Qualified Objects:

On a CL command, to reference on object in a specific library one would specify the library name first, followed by a forward slash, and then the object name (ie. MYLIB/MYOBJ). This is called "qualifying an object." In almost every AS/400 shop it's the rule that programs mustn't qualify objects unless it can't be helped. Programs should always depend on the job's library list to find objects unless circumstance dictate otherwise, such as in emergencies or if the program is temporary like a fix program or a kluge.

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 small numbers 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.

Most homegrown applications have between one and three libraries. Some have program, source, and files 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 the source into its own library.