Paging Space Data Sets

ASM defines three classes of paging space data sets, corresponding to the three logical groups of pages (pageable link pack area (PLPA), common, and local).
micsrm140
ASM defines three classes of paging space data sets, corresponding to the three logical groups of pages (pageable link pack area (PLPA), common, and local).
At least three paging data sets must be defined to the system. The first one is the PLPA data set, the second is the common data set, and the remaining data set(s) are used as local page data sets. You can define a fourth class of paging data set, the duplex data set, to provide a backup for the PLPA and common data set.
The term slot is used to characterize the location of a virtual page when it resides on an ASM data set, just as the term frame is used when a virtual page resides in real memory. When a page is resident on an ASM data set, it is said to occupy a slot. ASM paging data sets are sized in units of slots.
PLPA Data Set
The PLPA data set should be on a fixed-head device if possible. If not, make sure this data set is on a dedicated volume. Generally, a good starting point for sizing the PLPA data set is four megabytes. In MVS/XA systems, because of the potentially very large extended PLPA, this eventually may not be large enough, but it is a good place to start. If the PLPA data set is too small, it will spill into the common data set. Although this is not recommended, we give an example of how this might happen in ASM Usage Guidelines.
Common Data Set
The common data set should be large enough to hold all common system area and nucleus area pages (in MVS/XA the nucleus is conceptually included in the common area). As we noted for the PLPA data set, a reasonable starting point might be four megabytes (the same MVS/XA considerations apply), then adjust the size to the actual requirements.
When the common data set is too small, it will overflow to the PLPA data set. If this happens, ASM will not use the common data set again, even when slots become available. For this reason, you should avoid overflow from the common paging data set to the PLPA data set.
Duplex Data Set
The duplex data set should be large enough to hold both PLPA and common pages. Thus, it should be as large as the combined size of the PLPA and common page data sets. Generally, eight megabytes should be sufficient for systems through MVS/ESA. Again, you can use the Auxiliary Storage Management reports to determine size requirements for this data set.
Use of duplexing is not generally recommended because of the extra overhead involved in the duplex operation (an extra page-out is done for each common area page-out). If you use duplexing, we recommend that you evaluate the savings in terms of system down time to see if this option is still required.
Local Data Set
The total paging space provided by the local data sets must be sufficient to hold all private area pages and virtual I/O (VIO) data sets. An example of this size calculation is given in the Initialization and Tuning Guides. You can use the Auxiliary Storage Management reports at the monthly level to refine this value.
The local data sets should be sized to reflect the type and number of address spaces expected to be active concurrently, the private area for each, and the total amount of VIO pages required. System and started task address spaces require local page data set slots equivalent to their private area size. To help ensure that there will be enough ASM slots (sometimes referred to as backing slots or backing store) available for the address space paging, swapping, and VIO demands, MVS performs the function described below.
In pre-MVS/XA systems, at address space creation for TSO and batch, ASM divides the number of slots that would be required to contain the entire private area of the address space by a constant (ILRSLOTC, currently initialized to eight) and subtracts the result from the slot count for all local page data sets. The number of slots required for a VIO data set is divided by another constant (ILRSLOTV, currently initialized to four) and, again, the result is subtracted from the overall slot count. When there are no more slots available by this computation, further address spaces or VIO data sets are not allowed.
In MVS/XA and MVS/ESA systems, these functions are implemented through the ASMSLOTC (for non-VIO requirements) and ASMSLOTV (for VIO requirements) values. The calculations are as described for pre-MVS/XA systems, but the default assumptions are different. It is assumed in both MVS/XA and MVS/ESA systems that you have allocated enough paging space to accommodate the needs of your workload. Hence the default values for both parameters effectively turn off the backing store functions. The method of turning them on and adjusting them to the needs of your workload is described in the Initialization and Tuning Guide.
This algorithm is NOT based on the actual number of local paging data set slots currently in use. Instead, it attempts to predict the number of slots that will be used by an address space or VIO data set and effectively reserves that number of slots.
The PLPA and common data sets should be sized somewhat above the minimum requirements that can be calculated. A growth factor can be determined from the ASM Page/Swap Activity Report and should be included. This growth factor is typically 25 percent to 35 percent of the maximum slots used over the last four months.
Sizing of local data sets is somewhat more complex. If the data set is going to service group requests (swapping, VIO, virtual fetch), it should be large enough to make efficient use of the consecutive slot allocation.
In sizing the PLPA and common data sets, you should be aware that overflow from one data set to the other is allowed. In general, only overflow from PLPA to common should be accepted.
The following sections discuss the details of the paging algorithms used. For more details, see ASM Usage Guidelines.

Data Set Selection

For any page-in request, Auxiliary Storage Manager (ASM) must naturally select the page data set to which the virtual page was paged-out. To improve page fault response time, page-in requests are given priority over page-outs.
With the exception of a create LPA (CLPA) operation at IPL, pageable link pack area virtual pages are read-only, and are therefore paged-in from the PLPA data set, but never paged- out. Changed Common System Area (CSA) virtual pages are always paged-out to the common data set. The common and PLPA data sets may spill to one another, though common should not be allowed to spill to PLPA for performance reasons. For private area page-out processing, however, ASM must choose between the local data sets.
In MVS/XA and MVS/ESA, considerations are made for the projected response times of the individual page data sets. Page data sets with faster projected response times tend to be selected over those with slower projected response times, balancing the paging load to provide a more consistent level of paging response across page-out requests.
Naturally, there also must be enough space on the selected page data set to service the request. For a group (or related) request, this means enough contiguous slots. For a demand paging request, there must be enough slots to hold the pages to be paged-out.

Service Burst Calculation

The idea behind the service burst is to avoid long-running paging channel programs while address spaces are waiting for page fault resolution. The goal is to limit paging channel program execution to a fixed number of pages, device dependent.