The naming convention used for the IFS is based on the PC standard. A name takes the form DIR1\DIR2\…\DIRn\FILENAME. For those of us who can’t remember when to use a forward slash (/) and when to use a backward slash (\), the new naming convention happily accepts either — you can even mix them in the same name.

The lengths of the file and directory names have been increased to match the POSIX standards. In an AS/400, the names in the IFS directories are stored in a format called Unicode, which is an international standard that supports multiple languages, including the double-byte character sets many countries use. New for all RISC-based systems is the capability to store all data in the database in Unicode.

The IFS allows any client to look at a file stored in the AS/400 as if it were an extension of its own file system. Unix clients think they are dealing with a Unix file system, while PC clients (as shown in Figure 5.3) think the files are PC files. The beauty of this is that both clients can be looking at the same data, so there is no need to have separate copies of the data. Original PC clients and existing AS/400 applications continue to use QDLS and QSYS.LIB, respectively. New clients and new applications can use any of the supported file systems. PC and Unix users do not even need to learn the AS/400 control language, CL. They can use any of the commands and utilities that run on the DOS, Windows, or Unix systems they use today.

Keep in mind that the IFS provides access to the data. The format of the data must be compatible with the application requesting the data, or it must be converted to a compatible format. Note that OS/400 handles much of the conversion between data formats such as the Extended Binary Coded Decimal Interchange Code (EBCDIC) used for native AS/400 applications and the American Standard Code for Information Interchange (ASCII) used in the PC world.

The introduction of Unicode support for the database on RISC systems gives application developers the capability to use a universal data format that is being deployed across many platforms in the industry. This capability to use Unicode also means that a single application can be written for use worldwide; a special version of the program is not necessary for countries whose language requires a double-byte representation.

Accessing Objects

It is not enough to just find an object. Some means must be provided to allow a user program or an OS/400 program to access and modify objects. This occurs at the MI for system objects.

OS/400 is responsible for managing its own objects. It keeps track of the separate system objects that make up each OS/400 object. The object management component of SLIC manages the system objects and does not know about OS/400 objects. Again, the goal of the AS/400 design is to keep the two parts of the operating system, above and below the MI, independent. The only common ground between them is the MI, and it is here that access to objects is provided.

A system object is accessed with a system pointer. A system pointer occupies 16 bytes in memory and contains the address of the system object. A system pointer also contains information about the type of object to which it points. Chapter 8 describes the format of the system pointer in more detail.

Capability-Based Addressing

A system pointer also may contain information showing the types of operations that can be performed on the object. This information is usually called the object authority. A pointer that contains the object address and the object authority is called a capability. The System/38 had capability-based addressing, because all system pointers contained both the address and the authority. This changed in the AS/400.

The desire to increase the levels of system security for the AS/400 required changes to the way object authority was given to users. With the authority in the pointer, any user who has the pointer permanently has the authority to the object. The user may also be able to give the pointer or a copy of the pointer to another user.

Suppose we want to give a user the authority to an object to perform a single operation. The user’s program may need to temporarily access or modify data in the object, but the user does not need this authority permanently. But by giving the user authority in a system pointer, there is no way to take the authority back.

To limit user authority and increase security, IBM added methods to provide temporary authority to the AS/400. At the same time, we removed the authority from the pointers for all user programs. Pointers the operating system uses when in system state can still have the authority in the pointer. I explain all this further in Chapter 7 when I discuss security and authorization management.

Many people still talk about the AS/400 as a system having capability-based addressing. However, with the one exception just cited, the AS/400 does not use capability-based addressing.

Resolving System Pointers

A system pointer is said to be resolved if it contains direct addressability to the system object. If the pointer contains symbolic addressability to the system object, it is said to be unresolved. The symbolic address consists of the object’s name, type, and subtype. The subtype is not needed to uniquely identify an MI system object. It is the user-defined field that allows OS/400 to further categorize objects. The symbolic address is used to locate the object in a library.

Figure 5.4 shows how a system pointer is resolved by using the RESOLVE instruction. This instruction uses the name and type of the system object from the unresolved pointer, along with the authority being requested. The libraries in the library list associated with the job that issued the instruction are searched one at a time until the object is located. After the object is found, three checks are performed.

Figure 5.4  Resolving a System Pointer

First, the object type is checked to ensure that the instruction is expecting the correct type of object. Next, a check is performed to see whether the user has the right to obtain the authority requested in the RESOLVE instruction. This information is kept in the user profile. Finally, a check is made to see whether some other user has locked the object so it cannot be accessed.

If all checks are passed, the unresolved system pointer is updated to contain the address of the system object. As previously noted, the authority can be put in the pointer only for a program that operates in the system state. Once the pointer has been resolved, it can be used by the program for all subsequent accesses to the object; it is not necessary to re-resolve the pointer each time it is used.