In addition to the DAT hardware and the segment and page tables required for address translation, paging activity involves a number of system components to handle the movement of pages and several additional tables to keep track of the most current version of each page.

To understand how paging works, assume that DAT encounters an invalid page table entry during address translation, indicating that a page is required that is not in a real storage frame. To resolve this page fault, the system must bring the page in from auxiliary storage. First, however, it must locate an available real storage frame. If none are available, the request must be saved and an assigned frame freed. To free a frame, the system copies its contents to auxiliary storage and marks its corresponding page table entry as invalid. This operation is called a page-out.

After a frame is located for the required page, the contents of the page are copied from auxiliary storage to real storage and the page table invalid bit is set off. This operation is called a page-in.

Paging can also take place when z/OS loads an entire program into virtual storage. z/OS obtains virtual storage for the user program, and allocates a real storage frame to each page. Each page is then active and subject to the normal paging activity; that is, the most active pages are retained in real storage while the pages not currently active might be paged out to auxiliary storage.

Page stealing

z/OS tries to keep an adequate supply of available real storage frames on hand. When a program refers to a page that is not in real storage, z/OS uses a real storage page frame from a supply of available frames.

When this supply becomes low, z/OS uses page stealing to replenish it, that is, it takes a frame assigned to an active user and makes it available for other work. The decision to steal a particular page is based on the activity history of each page currently residing in a real storage frame. Pages that have not been active for a relatively long time are good candidates for page stealing.

Unreferenced interval count

z/OS uses a sophisticated paging algorithm to efficiently manage virtual storage based on which pages were most recently used. An unreferenced interval count indicates how long it has been since a program referenced the page. At regular intervals, the system checks the reference bit for each page frame. If the reference bit is off — that is, the frame has not been referenced — the system adds to the frame’s unreferenced interval count. It adds the number of seconds since this address space last had the reference count checked. If the reference bit is on, the frame has been referenced and the system turns it off and sets the unreferenced interval count for the frame to zero. Those frames with the highest unreferenced interval counts are those most likely to be stolen.

z/OS also uses various storage managers to keep track of all pages, frames, and slots in the system.

GDG is a collection of historically related non-VSAM data sets that are arranged in chronological order. Each data set within a GDG is called a generation data set (GDS) or generation.

Within a GDG, the generations can have like or unlike DCB attributes and data set organizations. If the attributes and organizations of all generations in a group are identical, the generations can be retrieved together as a single data set.

Generation data sets can be sequential, PDSs, or direct (BDAM). Generation data sets cannot be PDSEs, UNIX files, or VSAM data sets. The same GDG may contain SMS and non-SMS data sets.

Advantages to grouping related data sets include:

• All of the data sets in the group can be referred to by a common name.
• The operating system is able to keep the generations in chronological order.
• Outdated or obsolete generations can be automatically deleted by the operating system.

To define a GDG you must first create a GDG base. This base defines the base portion of the dataset names used by the GDGs as well as defining how many generations (files) can be stored within the GDG. Once this maximum number of generations is reached, creating a new generation will result in the oldest generation being discarded. A GDG can hold up to 255 generations.

The files within a GDG are assigned names derived from the name of the base and have a generation number added to the end so as to give each file a unique name.

For example:

GDG base name: TEST.DATASET

The first file created within this GDG will be given the name TEST.DATASET.G0001V00

Subsequent files will be named by incrementing the generation number:

G0002V00, G0003V00, etc. all the way up to G9999V00

Once the G9999V00 generation number is reached the numbering will start again from G0001V00.

Notes:

1.      The two zeroes on the end of the name are now usually used for version control.

2.      Only one version is kept for each generation.

Generation data sets have sequentially ordered absolute and relative names that represent their age. The operating system’s catalog management routines use the absolute generation name (ex: TEST.DATASET.G0002V00). The relative name is a signed integer used to refer to the latest (0), the previous (-1) and the next (+1), and so forth, generation.

Example:

Previous: TEST.DATASET(-1)

Current: TEST.DATASET(0)

Next: TEST.DATASET(+1)

Next +1: TEST.DATASET(+2)

Referencing the entire GDG

It is possible to reference the entire GDG as if it were a single file by using the base name instead of an absolute or relative file reference. All files within the GDG will then be processed starting from the oldest generation and ending with the latest one. Note that to be able to reference all of the generations at once in this way that all of the files need to be defined with the common Data Control Block information (ex: the same record length). If the files within a GDG are never to be referenced this way then there is no requirement that they have any file attributes in common.

Rolled in and rolled off

When a GDG contains its maximum number of active generation data sets in the catalog, defined in the LIMIT parameter, and a new GDS is rolled in at the end-of-job step, the oldest generation data set is rolled off from the catalog. If a GDG is defined using DEFINE GENERATIONDATAGROUP EMPTY and is at its limit, then when a new GDS is rolled in, all the currently active GDSs are rolled off.