Editing Data set (IBM mainframe) (section)

== Partitioned data set ==
{{anchor|Partitioned dataset}}{{anchor|Partitioned datasets}}{{anchor|Partitioned data sets}}
<!--confused? Someone dropped (an) anchor here, so let's honor it -->
{{confused|Passive data structure}}
A '''partitioned data set''' ('''PDS''')<ref>{{cite book
 | title = z/OS DFSMS Using Data Sets Version 2 Release 3
 | id = SC23-6855-30
 | date =  October 2, 2018 
 | section = Structure of a PDS 
 | url = https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sc236855/$file/idad400_v2r3.pdf
 | mode = cs2
}}</ref> 
is a data set containing multiple ''members'', each of which holds a separate sub-data set, similar to a [[directory (file systems)|directory]] in other types of [[file system]]s. This type of data set is often used to hold ''load modules'' (old format bound executable programs), source program libraries (especially Assembler macro definitions), [[ISPF]] screen definitions, and [[Job Control Language]]. A PDS may be compared to a [[ZIP (file format)|Zip]] file or [[COM Structured Storage]].

A Partitioned Data Set can only be allocated on a single volume and have a maximum size of 65,535 tracks.

Besides members, a PDS contains also a directory. Each member can be accessed indirectly via the directory structure. Once a member is located, the data stored in that member are handled in the same manner as a PS (sequential) data set.

Whenever a member is deleted, the space it occupied is unusable for storing other data. Likewise, if a member is re-written, it is stored in a new spot at the back of the PDS and leaves wasted “dead” space in the middle. The only way to recover “dead” space is to perform file compression.<ref name=Stephens>{{cite book|last1=Stephens|first1=David|title=What On Earth is a Mainframe?|date=Oct 2008|publisher=Lulu.com|isbn=978-1-4092-2535-5|page=52|url=https://books.google.com/books?id=1NMYOOW3gHMC|access-date=May 11, 2018}}</ref> Compression, which is done using the [[IEBCOPY]] utility,<ref>{{cite book
 | title = z/OS DFSMSdfp Utilities Version 2 Release 3
 | id = SC23-6864-30
 | date =  July 17, 2017 
 | publisher = IBM Corporation
 | section = Compressing a Partitioned Data Set 
 | quote = A partitioned data set will contain unused areas (sometimes called gas) where a deleted member or the old version of an updated member once resided. This unused space is only reclaimed when a partitioned data set is copied to a new data set, or after a compress-in-place operation successfully completes. It has no meaning for a PDSE and is ignored if requested.
 | url = https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sc236864/$file/idau100_v2r3.pdf
 | mode = cs2
}}</ref> 
moves all members to the front of the data space and leaves free usable space at the back.  (Note that in modern parlance, this kind of operation might be called [[defragmentation]] or [[garbage collection (computer science)|garbage collection]]; [[data compression]] nowadays refers to a different, more complicated concept.)  PDS files can only reside on [[direct access storage device|DASD]], not on [[magnetic tape]], in order to use the directory structure to access individual members. Partitioned data sets are most often used for storing multiple [[job control language]] files, [[IBM mainframe utility programs|utility]] control statements, and executable modules.

An improvement of this scheme is a [[Data Facility Storage Management Subsystem (MVS)#PDSE|Partitioned Data Set Extended]] (PDSE or PDS/E, sometimes just ''libraries'') introduced with [[Data Facility Storage Management Subsystem (MVS)#DFSMSdfp|DFSMSdfp]] for [[MVS/XA]] and [[MVS/ESA]] systems. A PDS/E library can store program objects or other types of members, but not both. BPAM cannot process a PDS/E containing program objects.

PDS/E structure is similar to PDS and is used to store the same types of data. However, PDS/E files have a better directory structure which does not require pre-allocation of directory blocks when the PDS/E is defined (and therefore does not run out of directory blocks if not enough were specified). Also, PDS/E automatically stores members in such a way that compression operation is not needed to reclaim "dead" space.<ref name=Stephens/> PDS/E files can only reside on DASD in order to use the directory structure to access individual members.