back to the general informations of PVS back to the general
informations of PVS:

PVS - dynamic Disk Management System
detailed Informations

The Present Situation while Processing Sequential Datasets

Due to the large dasd capacity, available nowadays, is seems to be usefull, to store sequential datasets on dasds und to hold multiple generations of a dataset. Under VSE resp. z/VSE this is only possible with a substantial effort, as A solution for these problems offers PVS - the dynamic disk management system.

Structure and function of PVS

The user defines, which dasds or dasd areas are to be controlled by PVS. These areas are called pools. Any number of pools may be specified, each with up to 16 areas. A pool can be accessed by a single or multiple real or virtual cpus concurrently.

PVS owns a unique catalog, in which all controlled, sequential datasets are entered. The datasets may be controlled by expiration date and/or number of generations.

PVS must be initialized during IPL in any partition. After initialisation, the partition is free again. PVS uses the vendor exits from the operating system to become active. Thus PVS gets control while a dasd file is opened or closed, if "end of extent" occurs and while end of task processing is performed.

Output of Sequential Dasd Datasets
Whether a sequnial output file is to be managed by PVS is specified by a specification of a relative start track of one in the EXTENT statement. Besides, PVS becomes active, if no EXTENT Statement is specified.

PVS needs a POOL Name for the allocation of the area for the output dasd file. Optionally, the pool name can be specified globally or explicitly in the EXTENT statement. In the latter case, the pool name is written in the place of the volser specification in the EXTENT statement.

PVS manages the usage of the pool areas by itself. Therefore, it can add the missing start track and size to an EXTENT statement or can add an EXTENT statement if none was specified to the DLBL statment. Thus, the annoying changing of these JCL statements can be omitted.

Optionally, an output dataset can be handled as a "single file" - that means, there is always onle one edition of this dataset - or as a "generation file" - which means, any number of editions of a dataset may be retained (under z/OS this is handled as a "generation-data-group" / GDG).

In the case of a GDG output, PVS supplements the file-id (44 characters in length) in its last 4 to 6 positiions by the generation numer in the form "G#" followed by a two to four numeric number indicating the generation of the dataset (G#01 to G#9999). Each new output of such a dataset increments the generation number by one. Each dataset holds the generation number assigned to it as long as it exists. The highest possible genration number is 9999.

Each dataset written to a pool is managed by PVS dynamically, that means, without any preceeding definition in the PVS catalog.

Optionalle, additional specifications may be made for a dataset. Either system wide or specificalle to this dataset. Those specifications may be the size of the first extent, (primary extent) the size and the number of the sequence extents as well as the expriation date and the nbr of generations to be retained.

When closing an output dataset, PVS releases the excessive dasd space, not needed for the file. This area may be immediately used by another file.

Only when a "normal" end of task is reache, all datasets created by this task are permanently entered to the PVS catalog. If there is an abnormal end of task, even the already closed datasets are deleted and the dasd space is released.

Input of a Sequential Dasd Dataset
With the open of a sequentila input dataset PVS becomes unconditionally active.

PVS checks, if the input dataset, only specified by a DLBL statement, is registered in its catalog. If yes, PVS completes the DLBL statement by one or more EXTENT statements. If necessary, an assignment is also build to the appropriate dasds.

If the input dasd has multiple generations (GDG), PVS selects usually the latest generation. Ofcourse, the user can specify a specific (generation nnnn) or relative (latest generation -n) generation in the DLBL statement.

Backup of the User Datas
PVS owns a flxible tool to backup the user data stored in one or more pools. The backup medium is always a tape or cartridge. Due to the high capacity of 30 GB and more, a restore of even a small file may take substantial time, as the tape must be read sequentilly to positition it to this file.

For this reason, PVS creates an index file while backing up the user data, which holds the physical position of each file on the tape. This file may be stored as a dasd dataset or as a sequence file on the backup tape or even both.

In the case of a restore, PVS can position the backup tape quickly to the required position to perform the desired restore.

Advantages of PVS
Since PVS is a new development, the hardware and software standards valid today could be respected.

PVS does not support ISAM and direct access datasets, as those are mostly converted by the operating system to VSAM datasets.

As nowadays dasd units usually own an own cache storage, PVS uses the regular VTOC without any indexing. Thus the overhead for I/Os and cpu time is avoided.

PVS has a transfer program to convert the catalog of other disk management systems into a PVS catalog.

Systemintegrity in PVS
PVS uses the vendor exits of VSE. Thus only official interfaces of the operating system are used.

Maintenance and Development of PVS
PVS is developed and maintained in Germany. The manuals are available in German and English language. verfügbar.

click here to go back to the general informations: get back to the general informations klick here to display or download the flyer of PVS to download the flyer of PVS in PDF format point to the icon, klick right mouse button and select "store destination"; to display the flyer click left mouse button