Data set (IBM mainframe)

In IBM mainframe computer environments, beginning with the IBM System/360 series, a data set (the preferred IBM terminology) or dataset refers to a computer file organized by records. This designation was first introduced with DOS/360 and OS/360 and continues to be used in later systems such as VSE and z/OS. Official manuals for these platforms consistently use this term instead of file.

Data sets are generally maintained on direct access storage devices (DASD) or magnetic tape, although devices like punch card readers and printers—classified as unit record equipment—can also function as input/output (I/O) peripherals for these data sets.

Unlike continuous byte streams without structure, data sets possess explicitly defined logical record and block formats. These are controlled by attributes such as DSORG (data set organization) and RECFM (record format). These settings are specified during the allocation phase, commonly through Job Control Language DD statements, and are handled during execution via control blocks like the Data Control Block (DCB) or Access Control Block (ACB). Records within a data set may have fixed lengths, variable sizes, or undefined lengths.

Data set organization

Within OS/360, the DSORG parameter in the DCB determines the organizational structure of the data set, including the following options:

CQ: Queued Telecommunications Access Method (QTAM) utilized in Message Control Program (MCP)
CX: Communications line group
DA: Basic Direct Access Method (BDAM)
GS: Graphics device for Graphics Access Method (GAM)
IS: Indexed Sequential Access Method (ISAM)
MQ: QTAM message queue within an application
PO: Partitioned Organization
PS: Physical Sequential

When dealing with tape storage, only DSORG=PS is applicable. The selection of organization depends on how the data will be accessed or updated.

Various access methods like QSAM or VSAM are employed by programs to interact with data sets based on their organizational type.

Record format (RECFM)

The consistent physical layout of records throughout a data set is defined by the DCB’s RECFM parameter. A value of RECFM=F signifies fixed-length records determined by LRECL. Conversely, RECFM=V indicates variable-length records that begin with a Record Descriptor Word (RDW), which specifies record size and control bits. Formats such as RECFM=FB and RECFM=VB represent fixed-blocked and variable-blocked records, respectively, grouping multiple logical records into a single physical block on tape or DASD. The RECFM=U format denotes undefined record length, where size depends on the block rather than an explicit control field.

The maximum block size is established by the BLKSIZE parameter. With RECFM=FBS (fixed-blocked standard), all blocks except possibly the last must be filled to full length. The RECFM=VBS (variable-blocked spanned) format permits logical records to extend across multiple blocks, utilizing RDW flags to mark continuation segments.

This approach eliminates the need for delimiter bytes between records, allowing the storage of binary integers, floating-point values, or character data without risk of misinterpreting record boundaries. Consequently, a data set represents an organized collection of records rather than an unstructured stream of bytes.

Partitioned data set

A partitioned data set (PDS) consists of multiple members, each functioning as an individual sub-data set, analogous to folders in other file systems. PDSs are typically utilized for storing load modules (linked executable programs), source code libraries such as Assembler macros, ISPF screen layouts, and Job Control Language scripts. They bear similarity to ZIP archives or COM Structured Storage.

Allocation of a PDS is restricted to a single volume, with a maximum capacity of 65,535 tracks. Besides the members themselves, a PDS contains a directory that facilitates indirect access to members; once accessed, each member operates like a sequential data set.

When a member is deleted, it results in unusable "dead" space within the PDS. Updating a member rewrites it at the end of the data set, causing fragmentation. To recover this wasted space, the IEBCOPY utility performs file compression by moving members toward the start of the PDS and freeing space at the end—similar to defragmentation or garbage collection processes. Due to its directory structure requirements, PDS files are stored exclusively on DASD and are prevalently used for job control language scripts, utility control statements, and executable modules.

An advanced iteration, the Partitioned Data Set Extended (PDSE or PDS/E), was introduced alongside DFSMSdfp for MVS/XA and MVS/ESA environments. PDSEs can hold either program objects or other types of members but not both simultaneously; notably, BPAM does not support PDSEs containing program objects.

PDSEs enhance PDS functionality by implementing dynamic directory allocation, which removes limits on preallocated directory blocks. They also automatically manage member storage to prevent fragmentation and eliminate the need for periodic compression. Like traditional PDS files, PDSEs reside solely on DASD to enable efficient member retrieval via their directory structures.

Generation Data Group

A Generation Data Group (GDG) is a collection of non-VSAM data sets representing sequential generations of related data maintained on IBM mainframe systems running OS/360 and its successors or DOS/360 and its successors.

Each element within a GDG is termed a "Generation Data Set" and can be referenced either by an absolute generation number (e.g., ) or relative numbers: indicating the previous generation, for the current generation, and for the next generation.

GDGs define retention parameters specifying how many generations to keep and when obsolete generations should be purged. Upon creation of a new generation, the system automatically deletes outdated generations, streamlining archival management through Job Control Language (JCL). Additionally, GDGs allow referencing all generations collectively in JCL by omitting parentheses and generation numbers.

GDG JCL & features

Generation Data Groups are established using either the BLDG statement of the IEHPROGM utility or the DEFINE GDG statement provided by the more recent IDCAMS utility. IDCAMS allows configuration of attributes such as:

, which limits the number of retained generations to 10.
, ensuring each generation remains for a minimum of 91 days.

IDCAMS also facilitates deletion and optional uncataloging of GDGs, improving lifecycle control.

Example

Creating a standard GDG with five retained generations and a minimum retention period of 35 days: <syntaxhighlight lang="jcl"> //STEP1 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DEFINE GDG (NAME('DB2.FULLCOPY.DSNDB04.TSTEST') LIMIT(5) SCRATCH FOR(35)) /* </syntaxhighlight>

Deleting an existing standard GDG: <syntaxhighlight lang="jcl"> //STEP3 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DELETE DB2.FULLCOPY.DSNDB04.TSTEST GDG FORCE /* </syntaxhighlight>

References

Introduction to the New Mainframe: z/OS Basics, Chapter 5, "Managing data sets," dated March 29, 2011.