Now that you understand that each job or user on an MVS system executes in a separate address space, you are ready to learn how MVS/370 organizes data within each address space. You should realize that some of the storage within an address space is required for various components of the operating system, some of the storage is required by the program or programs run by the job or user, and some of the storage is simply unallocated.

The following figure shows how a typical MVS/370 address space is organized. Here, you can see that the address space is divided into three basic areas: the system area, the private area, and the common area.

The system area and the common area are the portions of the address space that contain operating system programs and data. These areas are shared by all of. the address spaces on the system. In other words, the system area and the common area are the same for each address space.

The system area resides at the low end of the address space. It contains the MVS nucleus, which among other things controls the operation of virtual storage paging and swapping. The entire system area must be resident at all times, so it operates in real mode: It cannot be paged or swapped.

The common area, at the high end of the address space, contains additional components of the operating system. In particular, three important operating system components are in the common area—the system queue area, the pageable link pack area, and the common service area.

The system queue area, or SQA, contains important system tables and data areas that are used by programs residing in the nucleus; like the system area, the SQA is fixed in real storage. The common service area, or CSA, contains information that is similar to information in the SQA but that does not have to be fixed in real storage. The CSA, unlike the SQA, is pageable. The pageable link pack area, or PLPA, contains operating system programs that do not have to be fixed in real storage in the nucleus (the PLPA can also contain user programs that are heavily used). As its name implies, the pageable link pack area is not fixed in real storage.

Virtual Storage Address Space under MVS

Virtual Storage Address Space under MVS

The private area is the portion of an address space that contains data that is unique for each address space. Within each job's or user's private area, there are three basic areas. At the bottom of the private area is the system region, an area of storage used by operating system programs that provide services for user programs running in the private area.

At the top of the private area are three local system areas that contain information that applies only to the private area of a particular address space. The local system queue area, or LSQA, contains tables used to control the private area, including the tables needed to manage the private area's virtual storage. It is the LSQA that is written to the swap data set when an address space is swapped out. The scheduler work area, or SWA, contains tables used to manage the execution of jobs and programs within the private area. The third system area, called subpool 229/230, contains additional system information.

The rest of the private area, which comprises most of the address space, is either unallocated or allocated to a User region. It is in the user region that your program or programs actually execute. The size of the user region varies depending on the amount of storage required by the program being executed. If necessary, the user region can allocate all of the storage between the system region and the LSQA, SWA, and subpool 229/230. On most MVS systems, that amounts to about 10MB to 12MB.

Virtual Storage Address Space for Multiple Address Spaces under MVS

Virtual Storage Address Space for Multiple Address Spaces under MVS

The system area and the private area are accessible to all address spaces, but the private area is unique to each address space. That way, critical components of MVS that reside in the system area and the common area are available at all times, no matter which address space currently has control of the CPU. To understand this, consider the above figure. Here, you can see that four address spaces share the system and common areas and retain unique private areas. If the system and common areas were not shared in this way, that information would have to be duplicated in each address space. The shading indicates storage allocated from the private area. In address space 4, all of the available storage in the private area has been allocated.

Address Space Organization under MVS/XA and MVS/ESA

Newer models of System/370 family processors provide an addressing mode in which 31-bit addresses rather than 24-bit addresses can be used. One of the major problems IBM faced when making this change was keeping these new processors compatible with the old processors. In other words, programs written with 24-bit addresses must still be able to run properly on processors that provide 31-bit addresses.

Virtual Storage Address Space under MVS/XA and MVS/ESA

Virtual Storage Address Space under MVS/XA and MVS/ESA

To provide that compatibility and still reap the benefits of 31-bit addressing, processors that use 31-bit addresses and the operating systems that support them provide a full 2GB address space, but they include special provisions for addresses below 16MB. In short, the first 16MB of an address space can be accessed using 31-bit or 24-bit addresses. So 24-bit programs can run unchanged, still restricted by the 16MB limitation, while 31-bit programs can use the full 2GB address space.

Because of this arrangement, the layout of an XA or ESA address space is different than you might expect. The above figure illustrates the layout of an address space under MVS/XA or ESA. The first thing to notice is that the address space is logically divided at the 16MB line. Even though in the figure the 16MB line is placed at about the halfway point, in an actual address space, 16MB is less than one one-hundredth of the total address space.

Under XA or ESA, there is no system area; instead, the MVS nucleus is combined with the other operating system data in the common area. As a result, an XA or ESA address space has two types of areas: the common area contains the operating system and is common to all address spaces, and the private area contains the data that is unique to each job's or user's address space, including the program that is being executed. In addition, an XA or ESA address space provides two sections of each area: one below the 16MB line, the other above it. So, in Figure , the private area resides below the 16MB line, and the extended private area resides above it. Similarly, the common area is below the 16MB line, and the extended common urea is above it.

Notice the peculiar arrangement of the common area and the extended common area, which bracket the 16MB line. The nucleus occupies the highest locations of storage below the 16MB line, while the extended nucleus occupies the lowest locations above 16MB. As a result, the nucleus and the extended nucleus occupy a continuous range of addresses that cross the 16MB line. The system queue area (SQA), pageable link pack area (PLPA), and common service area (CSA) also have two parts each: one below and one above the 16MB line.

It might seem as if splitting the private areas by placing the common areas between them would cause problems for large programs that require virtual storage allocated for an extended User region (the portion of the user region that resides above 16MB). But that is not the case. Programs that use space from the extended user region treat both parts of the user region as if they were one continuous area. In any event, few programs use all of the private area available under MVS, let alone require space in the extended private area above 16MB.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

IBM Mainframe Topics