Finding Objects

In the original System/38, it was fairly easy to find an object in the database. Because every object had a name, you simply looked up the name in a library. A library provided a means to organize objects into groups and allowed objects to be found by name. The same library structure was brought forward into the AS/400.

Libraries

A library is an OS/400 object that you use to find other OS/400 objects in the database. The library is organized as a single-level hierarchy, unlike the directory structure found on PCs and in the Unix operating system, which have a multilevel hierarchy. A look at the naming structure for OS/400 objects will illustrate this hierarchy.

To find an OS/400 object requires the name of the library and the name of the object (i.e., LIBRARY/OBJECT). You also need the object type to uniquely identify the object. Two or more objects can have the same name, but they must be different types of objects. In other words, in a library we can have a program named SAM and a data space named SAM, but we can’t have two programs named SAM. Also, an object can exist in one and only one library.

With one exception, a library cannot reference other libraries. To do so would violate the single-level hierarchy of LIBRARY/OBJECT. There is, however, a special library called QSYS that can reference other libraries, and it is the only one that can do so. A few other special OS/400 objects also can appear only in QSYS. The user profile objects, which give security authorizations to users, and the I/O configuration objects, which are used for I/O operations, can appear only in QSYS. We discuss these objects in detail in later chapters.

Figure 5.2 shows the OS/400 library structure. In this example, QSYS contains a user profile (JOHN), a library (LIB1), and a device description (DEVD1). The library (LIB1) contains a database file (DB), a data queue (DQ), and an output queue (OQ).

Figure 5.2  OS/400 Library Structure

Later, we will see that a list of libraries accompanies each job in the system. This list tells the system which libraries to search when looking for an object and the order in which to search the libraries.

Shared Folders

Shared folders were introduced in the AS/400 primarily to support Office functions. The System/36 was a very good Office system, and many of the ideas about folders on the AS/400 came from this system. An OS/400 folders object was added to support these Office functions. Briefly, the integrated Office support provides a filing system for all Office objects that can contain data for an Office product. Mail, documents, programs, and files are among the traditional items that can be in this filing system.

Document library services allow users to treat the filing system as an electronic filing cabinet complete with folders. Folder management services allow the user to organize objects using these folders. Folders can contain other folders and can be searched interactively.

The desire to efficiently incorporate PCs into this Office environment led to the use of shared folders for the PC Support product on the System/36. This approach was carried forward into the AS/400. Thus, in addition to the traditional Office items mentioned, shared folders can contain spreadsheets, graphs, images, PC programs, and PC files.

PC files stored on the AS/400 can be accessed by the PC as if they were stored locally on the PC. Files can be transferred to and from the PC, with the data conversions automatically performed. Multiple sessions on the PC allow it to interact with multiple AS/400 systems, with multiple tasks on a single AS/400, or with any combination of both.

IBM enhanced PC Support several times, but the product was getting old and fell short of what was needed for newer client/server applications. Also, PC Support didn’t support all the PC operating systems customers wanted to use. While it provided the ability to attach PC clients that ran DOS, DOS with Extended Memory, and OS/2, it was noticeably lacking Microsoft’s Windows operating system. PC Support needed major changes.

IBM replaced PC Support with a totally new product called Client Access for OS/400, which provides a powerful platform for distributed client/server computing. To support some of the new clients, changes also had to be made to the AS/400’s file system. Libraries for database serving, and folders for Office and PC file serving, worked well for their original intended uses, but more was needed. The result was a new file system.

The Integrated File System

What if a PC file system, a Unix file system, the OS/400 library system, and OS/400 shared folders were combined into a single structure? This would mean that an application written to use a PC or Unix file system could directly access data stored in an AS/400. Such a file system was announced as a part of V3R1 and was called the integrated file system (IFS). IFS integrates all file systems on the AS/400 with one interface and one set of rules. Further, any user of Client Access for the newest Windows or OS/2 clients can view and manage libraries, folders, and all the new file systems graphically from their workstations.

Initially, the major challenge had been to determine how to construct such a file system. After all, the separate file systems were not designed to be compatible with one another, let alone be combined into a single structure. The problem turned out to be easier to solve than we initially had expected.

Notice in Figure 5.2 that the OS/400 library structure is a subset of that used in PC operating systems, such as DOS and OS/2. The names are different in the PC world, but the structure is similar. The PC operating systems have files instead of objects. A library in a PC is called a directory, and files exist in directories. Unlike the OS/400 library structure, directories can exist in directories on the PC; these are usually called subdirectories. This arrangement creates a multiple-level hierarchy for PC file naming as opposed to the single-level structure of the OS/400 library. A PC file name can take the form DIR1\DIR2\…\DIRn\FILENAME. Except for the backward slashes (\), this is a superset of the OS/400 library naming structure.

A Unix file structure is, likewise, a superset of the OS/400 library structure. Remember that an OS/400 object can appear only in a single library. That means there is only one path to any OS/400 object. A Unix file system allows multiple paths to the same object.

Our answer to combining all these file systems was to use a single root from a PC-like file system and to put all others under this root. Figure 5.3 shows how a Windows client can view the entire AS/400 and all file systems. The AS/400 in this figure is represented as a single drive. On that drive are PC-style directories, Unix-style directories, OS/400 libraries (QSYS.LIB), OS/400 shared folders (QDLS), and several other file systems that have been added to support new applications. Among the additional file systems are a fully POSIX-compliant file system (QOpenSys), a file system for LAN server clients (QLANSrv), a file system for Novell Netware (QNETWARE), and Sun Microsystems’ Network File System (QNFS). Other file systems are already supported, and new ones will be added in the future as more and more types of applications and their file systems find their way onto the AS/400.

Figure 5.3  Windows Client View of Integrated File System