A PDS data set offers a simple and efficient way to organize related groups of sequential files. As for most things, the PDS structure offers advantages but also has some disadvantages.

The PDS structure was designed to provide efficient access to libraries of related members, whether they be load modules, program source modules, JCL or many other types of content. Many system data sets are also kept in PDS data sets, especially when they consist of many small, related files. For example, the definitions for ISPF panels are kept in PDS data sets.

A primary use of ISPF is to create and manipulate PDS data sets. These data sets typically consist of source code for programs, text for manuals or help screens, or JCL to allocate data sets and run programs.

A PDS has the following advantages for z/OS® users:

• Grouping of related data sets under a single name makes z/OS data management easier. Files stored as members of a PDS can be processed either individually or all the members can be processed as a unit.
• Because the space allocated for z/OS data sets always starts at a track boundary on disk, using a PDS is a way to store more than one small data set on a track. This method saves you disk space if you have many data sets that are much smaller than a track. A track is 56,664 bytes for a 3390 disk device.
• Members of a PDS can be used as sequential data sets, and they can be appended (or concatenated) to sequential data sets.
• Multiple PDS data sets can be concatenated to form large libraries.
• PDS data sets are easy to create with JCL or ISPF; they are easy to manipulate with ISPF utilities or TSO commands.

PDS data sets are simple, flexible, and widely used. However, some aspects of the PDS design affect both performance and the efficient use of disk storage, as follows:

• Wasted space

  When a member in a PDS is replaced, the new data area is written to a new section within the storage allocated to the PDS. When a member is deleted, its pointer is deleted too, so there is no mechanism to reuse its space. This wasted space is often called gas and must be periodically removed by reorganizing the PDS, for example, by using the utility IEBCOPY to compress it.

• Limited directory size

  The size of a PDS directory is set at allocation time. As the data set grows, it can acquire more space in units of the amount you specified as its secondary space. These extra units are called secondary extents.

  However, you can store only a fixed number of member entries in the PDS directory because its size is fixed when the data set is allocated. If you need to store more entries than the existing directory space will hold, you have to allocate a new PDS with more directory blocks and copy the members from the old data set into it. This fact means that when you allocate a PDS, you must calculate the amount of directory space you need.

• Lengthy directory searches

  An entry in a PDS directory consists of a name and a pointer to the location of the member. Entries are stored in alphabetical order of the member names. Inserting an entry near the front of a large directory can cause a large amount of I/O activity, as all the entries behind the new one are moved along to make room for it.

  Also, entries are searched sequentially in alphabetical order. If the directory is very large and the members small, it might take longer to search the directory than to retrieve the member when its location is found.