Extent - Allocated space

Enhanced Definition

An extent in the mainframe context refers to a contiguous block of physical storage space on a Direct Access Storage Device (DASD) that is allocated to a dataset. A dataset can be composed of one or more extents, which collectively form its total allocated space on a volume.

Key Characteristics

- Contiguous Allocation: An extent is always a single, unbroken block of tracks or cylinders on a DASD volume, ensuring physical contiguity.
- Primary and Secondary: Datasets are typically allocated with a primary extent; if this space is exhausted, z/OS can allocate additional secondary extents.
- Space Units: Extents are defined and allocated in specific units such as tracks, cylinders, or blocks, as specified in JCL's SPACE parameter.
- Volume Specific: Each extent resides entirely on a single DASD volume. While a dataset can span multiple volumes, each individual extent is confined to one.
- Limited Number: Non-VSAM datasets have a limit on the number of extents they can have on a single volume (e.g., 16 for standard datasets, more for extended format or VSAM).
- Fragmentation Impact: Multiple extents for a single dataset can lead to storage fragmentation, potentially affecting I/O performance due to increased head movement.

Use Cases

- Dataset Creation: When defining new sequential, partitioned (PDS/PDSE), or VSAM datasets using JCL, the SPACE parameter specifies the size of the primary and secondary extents.
- Temporary Work Files: Programs requiring temporary storage (e.g., COBOL SORT work files) dynamically allocate extents on scratch volumes to hold intermediate data.
- Database Storage: DB2 table spaces, IMS datasets, and other database components are allocated as extents on DASD to store their data segments and indexes.
- System Logs and Spool Files: Critical system datasets like SMF (System Management Facilities) logs or JES (Job Entry Subsystem) spool files are allocated with extents to capture continuous operational data.

Related Concepts

Extents are fundamental to DASD (Direct Access Storage Device) management, representing the physical allocation of space. They are directly managed by z/OS Data Facility Product (DFP), which handles all storage allocation and deallocation requests. The concept is central to JCL (Job Control Language), particularly the SPACE parameter, which dictates how extents are initially allocated. The number and distribution of extents significantly impact I/O performance and can lead to ABENDs (e.g., B37 for no more space on the volume, D37 for no more secondary extents). VSAM (Virtual Storage Access Method) datasets also use extents, but often manage them more flexibly and efficiently than non-VSAM datasets, especially with SMS.

Best Practices:

Optimal Primary Extent Sizing: Allocate a primary extent large enough to accommodate most of the expected data, minimizing the need for secondary extents and reducing fragmentation.
Monitor Extent Count: Regularly monitor the number of extents for critical datasets. High extent counts can indicate inefficient space utilization and potential B37 or D37 ABENDs.
Reorganize Fragmented Datasets: For datasets with many extents, consider reorganizing or reallocating them to consolidate space into fewer, larger extents, which can improve I/O performance.
Leverage SMS Policies: Utilize Storage Management Subsystem (SMS) to automate and standardize dataset allocation, including extent sizing and placement, based on defined storage policies.
Plan for Growth with Secondary Extents: Ensure secondary extents are adequately sized to handle anticipated data growth without frequently requesting new extents, but avoid excessively large secondary extents that might waste space.
Use Extended/Large Format Datasets: For very large datasets, use SMS-managed extended format or large format datasets, which support more extents and larger individual extent sizes, mitigating traditional extent limitations.