)
Figure 5.6 System Object Structure
| Previous | Table of Contents | Next |
Temporary objects disappear at each IPL. In a conventional system, temporary memory areas are associated with user jobs and cannot be shared among users. When the job goes away, so do the temporary areas. In an AS/400, all memory, whether it contains permanent or temporary objects, can be shared among users. Even if the job goes away, the objects remain in the system. When the system was designed, some time, other than job termination, had to be designated when temporary objects would be removed from the system, and IPL time was selected. IPL time was a convenient time to choose to destroy temporary objects, because this resulted in less overhead during execution time. If, for example, we destroyed a job’s temporary library when the job ended, there would be some performance impact on the running jobs. So we decided to move that overhead to IPL time.
An example of an object that might be created as temporary is a data-space index, which provides a view of the database for some specific job. If this index is created only for a one-time query of the database, there is no sense to making it permanent. Note that a permanent object can ride out a system crash. But if the system has to be IPLed to recover, all temporary objects are lost. Objects sometimes are created as permanent simply to survive such a crash. In a later section, I explain how temporary and permanent objects are handled internal to the system.
So far, we have described only system objects and their characteristics. But at the MI there are other data items also called objects, and these data items have little or no resemblance to an object as it is commonly defined. This creates another terminology problem for us.
In Chapter 4, we examined the contents of an original MI program template — the instruction stream and the object definition table (ODT). The ODT describes the operands the program uses. In an unfortunate choice of names, the System/38 MI designers called these operands objects. Specifically, they called them program objects. Thus, a two-byte binary number is called an object.
These program objects have nothing in common with MI system objects except for the name. But because it is just too easy to confuse a program object with a system object of type program, we will simplify matters and reserve the name object from this point on to describe MI system objects only.
Although there is no concept of memory at the MI, all AS/400 processors make use of physical storage, including main memory and disk. System objects below the MI are implemented as well-defined data structures contained in that storage. The object management component of SLIC is responsible for creating and managing these data structures. In this section, we look at the layout of these data structures and see how they are used to represent MI system objects.
The notion of memory and disk space exists only below the MI. Unlike OS/400, the SLIC component of the operating system knows about and deals with this memory. All the main memory and disk space in an AS/400 is contained within a single, large address space. This address space is usually called the single-level store of the AS/400, and it consists of the total number of bytes that can be referenced with a 64-bit address.4
4The number of bytes in a 64-bit address is so large that most people cannot relate it to anything they know in the physical world. When the AS/400 had a 48-bit address, we would often say the number of bytes that could be addressed was equal to the distance from the earth to the sun and back measured in millimeters. Some new analogy is needed for 64 bits.
Single-level store is the AS/400 version of a virtual memory. Virtual memory provides a logical view of memory that does not necessarily correspond to the memory’s physical structure. In Chapter 8, I describe the differences between a virtual memory found in a conventional system and the single-level store of the AS/400. For now, it is enough to think about the single-level store as a very large address space with everything contained within it.
The entire address space in an AS/400 is logically divided into segments. A segment is a block of contiguous bytes in the address space. The System/38 and the original AS/400 had two segment sizes: 64K and 16 MB. The 16 MB segment consisted of 256 of the 64K segments and was sometimes called a segment group. With the move to a 64-bit address, the smaller size was dropped and only a 16 MB segment size is used.
Segments are nonoverlapping and always start on a segment boundary. This means that the address of the first byte in every 16 MB segment has the low-order (rightmost) 24 bits set to all zeros. Each 16 MB segment is uniquely identified by the high-order (leftmost) 40 bits of the 64-bit address.
The AS/400 address space is mapped onto the physical main memory and the disks by SLIC’s storage management component. This logical-to-physical memory mapping uses blocks of memory that are each 4K in length, called pages.5 A segment is composed of a multiplicity of these pages that are not necessarily contiguous in physical memory. I cover the details of this mapping in Chapter 8.
5The System/38 and the original AS/400 used a 512-byte page size. This was increased to 4K for the systems with the 64-bit RISC hardware.
Figure 5.6 shows the format of a system object in the single-level store. The first 32 bytes contain the segment header. The segment header provides information about the segment itself. Following the segment header is the Encapsulated Program Architecture (EPA) header. The EPA was created to specify the internal structure of the System/38’s encapsulated objects. This same internal structure was carried over into the AS/400. The EPA header contains the attributes (kinds of properties) common to all system objects, regardless of type. Both the segment header and the EPA header occupy the first 256 bytes in every system object and will be described in more detail shortly.
Figure 5.6 System Object Structure
Each type of object has kinds of properties found in only that specific type. A program has unique properties that a data space doesn’t have, and vice versa. A customized header, which contains the values of these special properties, follows the EPA header in the object.
Following these three headers are the components that make up the particular object. For example, the instruction stream follows the customized header in a program. Because all system objects have a space portion, a space component is always present. At the MI, this space component is called the associated space. The specific components, and the order in which they appear, are dependent on the object type. There are too many types of system objects to describe the customized headers and the object components in any detail. We look, however, at some examples in a later section.
| Previous | Table of Contents | Next |
){kind=link}