)
Figure 5.7 Multisegment Objects
| Previous | Table of Contents | Next |
System objects occupy one or more segments and always start on a segment boundary. The first segment is called the base segment, and every object has a base segment. A system pointer always points to the base segment. Depending on the type of object, there may be one or more secondary segments. Most objects have an associated space that occupies one of these secondary segments. Further, no segment is ever part of more than one system object.
Figure 5.7 shows a system object that occupies two segments. As shown, the system pointer points to the base segment. Notice that each segment has its own segment header. The segment header contains information about the segment, not about the object in the segment. The segment header also contains the addresses that link the segments together. Also note that the EPA header is contained only in the base segment. The EPA header contains information about the total object and needs to appear only in one place. Following the EPA header is the customized header for the object. Again, this header appears only in the base segment.
Figure 5.7 Multisegment Objects
These multiple segments are allocated at the time the system object is created. This allocation is accomplished through a CREATE xxx instruction, where xxx is the type of object being created. Figure 5.8 shows the input and the output for a CREATE instruction at the MI. The CREATE instruction uses a space pointer to point to the object template contained in a space object. Readers should be aware that MI CREATE xxx instructions are not the same as OS/400 CRTxxx commands. CRTRPGPGM must go through several preliminary passes before reaching the MI CREATE. The latter is the last pass of a program compile. The execution of the MI CREATE instruction causes the base and secondary segments to be created in the single-level store. Various directories managed by the SLIC are updated to reflect the presence of the new object.
)
Figure 5.8 Object Creation
Storage management needs to have access to the segments, and one of its directories is updated. If the object appears in a library, the library (context below the MI) must be updated to contain the name and location of the new object. If no library is specified, the object is placed in the current library of the job that issued the CREATE instruction. One of the libraries in the library list for every job is always identified as the current library. Likewise, the user profile or group profile must be updated to show the ownership of the new object. The final step is to create a system pointer to the object and pass it back to the user who requested the creation of this object.
Now that we have examined the structure of the system objects and how they map to memory segments, we can look at the contents of both the segment headers and the EPA headers. As we saw in Figure 5.6, a segment header occupies the first 32 bytes of each segment that makes up a system object. An EPA header appears only in the base segment of a system object.
A segment header provides the following information about a segment:
These last two addresses should not be confused with the system pointer and the space pointer to the system object. They are the 64-bit addresses the SLIC uses.
The segment-type byte identifies what is in the segment. There are two categories of segment types: those that are part of MI objects and those that are used by only SLIC below the MI. Until now, we have considered only segments that are used for MI objects. There is, however, a whole category of segments for SLIC data structures that are not part of the MI system objects; but these segments are not treated as entities, as an object would be.
We have already seen two types of segments that are part of a system object. The first segment type was the base segment of a system object. The second was the associated space segment. About a dozen other segment types can be part of the various MI system objects. The system object examples shown in the next section illustrate a couple more of these MI object segments. We introduce still others in the following chapters when we cover the topics to which they are related.
Approximately 40 segment types are used only by the SLIC. Everything from storage management tables to the work area used by the translator have their own segment types. Again, it makes sense to delay discussing these segment types until we encounter them in the following chapters. For now, it is only important to understand that they exist, and that they are constructed and managed similarly to the segments used for system objects.
A segment header contains several flag bits that identify characteristics of the segment. Three of the most important flags are the existence, autoextend, and tags-in-segment bits. The existence bit identifies whether the segment is permanent or temporary. Unless it is explicitly destroyed, a permanent segment stays in the system forever, whereas a temporary segment goes away whenever the system is IPLed.
The autoextend bit tells storage management to add disk pages to the segment whenever they are needed. Note that there is a field in the segment header that tells the number of disk pages allocated to the segment. If the autoextend bit is turned off, this means the segment will never grow beyond the size it was when it was created. Whenever this bit is off, storage management attempts to put the entire segment into a contiguous area on disk when the segment is created. If the bit is on, the segment is likely to be composed of noncontiguous pages on disk. Thus, turning the bit off can improve performance at the cost of pre-allocating all the pages.
| Previous | Table of Contents | Next |
){kind=link}
){kind=link}