Chapter 3
The System Licensed Internal Code

“Will the real AS/400 operating system please stand up?” Some confusion has always existed about where to find the operating system in the AS/400. The obvious answer to our question seems to be OS/400; after all, we wouldn’t have called it Operating System/400 if it was not the AS/400’s operating system. But wait a minute. OS/400 can’t be the correct answer, because OS/400 lacks most of the functions found in other operating systems.

In Chapter 1, we defined an operating system as a collection of programs that manage the system resources and provide a base for writing application programs. We also saw that the AS/400’s high-level machine interface, called the MI, is a complete set of APIs for writing applications. Therefore, the MI provides a base for applications. The question then is, “Where are the programs that manage the system resources?”

If we answer OS/400, we would again be wrong. Traditional operating-system components handle functions such as memory, process, program, and I/O management. But these low-level functions tend to be hardware dependent, tied closely to the underlying physical structures. For example, the memory-management component must know the exact configuration and characteristics of the memory hierarchy. The MI is a technology-independent interface that has no knowledge of the memory configuration and characteristics. Thus, memory management needs to be handled below the MI.

Because OS/400 resides above the MI, none of these hardware-dependent components can be in OS/400. They are part of the operating system of the AS/400, but they must be beneath the MI to preserve technology independence. In this way, the MI protects application programs and OS/400 from hardware changes. The operating-system software beneath the MI is called the licensed internal code (LIC).

Let’s review the structure of the AS/400 as we now see it. By now the distinction should be clear: OS/400 consists of objects and programs above the MI. The LIC comprises the data structures and programs below the MI — the LIC is the link between the MI and the hardware. In fact, the AS/400’s operating system is the combination of OS/400 and the LIC. So if the AS/400 is the cake, then OS/400 is the frosting on the cake and the LIC is the frosting between the layers of the cake.

In recent years, this underlying part of the operating system in other systems has been called the kernel. There are many definitions of just what belongs in the kernel of an operating system. Some purists would argue that the LIC contains far more operating-system function than is normally found in a kernel. Regardless, the term kernel is a convenient way to describe the operating-system functions packaged under the MI.

Divide and Conquer

It is obvious that some operating-system components, such as memory management, belong in the LIC. Other system components are not so clearly defined. Look at a database. Parts of a database implementation may need to know about the physical disk drives and how to transfer data in the system. Still other parts of the database implementation can be written to be hardware independent. The designers must decide where to put the database software — all in OS/400, all in the LIC, or some in each.

At the risk of getting too far ahead of our discussion about the MI in Chapter 4, I should note that when I use this two-part division between OS/400 and LIC, I’m thinking of objects in the MI that have LIC implementations. In Chapter 4, we will see that there are MI system objects that have LIC implementations, and there are OS/400 objects that have only MI implementations.

Of course, all OS/400 functions have LIC implementations in the sense that they must go through the MI to communicate with the hardware. But, in many cases, an instruction in an HLL, after being converted into its MI form, is translated directly in PowerPC (or to the older IMPI) instructions without reference to any special LIC data structures or calls to LIC routines. A particular system function may be said to be implemented in OS/400 and not in the LIC if the code that implements the function is visible to OS/400 and the data structures required for the function are found in OS/400 objects or their visible parts.

Figure 3.1 shows the split of various operating-system functions between OS/400 and the LIC. Some functions, such as work management, which schedules jobs in the AS/400, can be predominantly in OS/400, because such functions have few hardware dependencies. Other functions, such as device support, can be partially in OS/400 and partially in the LIC. The generic characteristics of a device can be in OS/400. For example, knowing that a device is a printer does not tie the application program to a specific printer. However, knowing the details of the printer data stream does tie a program to a specific printer, and this information needs to be in the LIC below the MI.

Figure 3.1  AS/400 Function Split

Some operating-system functions that are not hardware dependent are also packaged below the MI. Consider security, for example. Security has no hardware dependencies, so it could be totally in OS/400 above the MI. Parts of security, however, should be below the MI to provide a higher degree of protection. In Chapter 7, we will see that system-wide security is in OS/400, while the authorization to system resources is below, in the LIC.

Most major operating-system functions, like security, have some portions above and some portions below the MI. Even the individual components of an operating-system function can be split across this boundary. Figure 3.1 also shows a breakout of some components in the database and how they are split across the MI.

Another reason for moving a function or part of a function below the MI is performance. In general, as a function becomes more and more hardware dependent, it can be tuned to achieve higher performance for a given hardware implementation. Moving these functions below the MI does not guarantee higher performance for all functions, but it does help some. The downside to doing this is that more code in the operating system becomes dependent on the underlying hardware.