EATTR - Extended Attributes

Enhanced Definition

`EATTR` (Extended Attributes) is a data set attribute in z/OS that controls whether a data set can utilize Extended Address Volumes (EAVs) and/or be allocated in extended format. When set to `OPT` (optional), it allows the data set to reside on EAVs beyond cylinder 65520 and/or leverage extended format features like striping and larger block sizes. `EATTR` (Extended Attributes) is a dataset attribute in z/OS that indicates whether a dataset can reside on an `Extended Address Volume (EAV)` and/or utilize `Extended Format` characteristics. Setting `EATTR=OPT` allows datasets to exceed traditional volume size limits and leverage advanced features like larger block sizes and striping.

Key Characteristics

- Scope: Primarily applies to VSAM data sets (KSDS, ESDS, RRDS, LDS) but also to some non-VSAM data sets (sequential, PDS/PDSE).
- Values: Can be OPT (optional) or NO. OPT enables the use of EAVs and/or extended format; NO restricts it to traditional volumes and formats.
- Default Behavior: The system default for EATTR can be set in the IGDSMSxx PARMLIB member (EATTR(OPTIONAL) or EATTR(NO)). If not explicitly specified, it can also be inherited from the assigned SMS storage class.
- Specification: Can be specified during data set allocation via JCL (DCB=EATTR=OPT), IDCAMS DEFINE CLUSTER command (EATTR(OPTIONAL)), or through the attributes of an SMS storage class.
- Prerequisite for EAV/Extended Format: Setting EATTR=OPT is a mandatory prerequisite for a data set to be eligible for allocation on an EAV volume beyond the 65520 cylinder boundary or to be created as an extended format data set.
- Impact on Capacity: Enables data sets to grow beyond the traditional 4GB limit when combined with EAVs and extended format.

Use Cases

- Large Data Set Allocation: Creating VSAM KSDS, ESDS, or large sequential data sets that require more capacity than traditional volumes offer, by placing them on Extended Address Volumes (EAVs).
- Performance Enhancement: Utilizing extended format data sets with striping across multiple volumes or devices to improve I/O throughput for high-performance applications.
- SMS Policy Enforcement: Defining SMS storage classes where EATTR=OPT is a default or required attribute, ensuring that data sets managed by those classes can leverage modern storage capabilities.
- Capacity Management: Facilitating the migration of existing data sets to EAVs to consolidate storage and optimize space utilization without requiring application changes.

Related Concepts

EATTR is fundamentally linked to Extended Address Volumes (EAVs) and Extended Format Data Sets. It acts as a crucial flag that permits a data set to utilize these modern storage capabilities. While EAVs provide significantly larger storage capacity and extended format enables features like striping and larger block sizes, EATTR=OPT must be set for a data set to be eligible for either. It works in conjunction with SMS (Storage Management Subsystem), where storage classes can dictate the EATTR setting, influencing where and how data sets are allocated and managed.

Best Practices:

Default EATTR=OPT for New Allocations: For most new VSAM and large sequential data sets in modern z/OS environments, configure SMS storage classes or system defaults to EATTR=OPT to allow for future growth and EAV utilization.
Verify Application Compatibility: Before widely adopting extended format data sets, especially those with striping, ensure that any legacy applications or utilities that directly manipulate data set structures are compatible.
Explicitly Specify When Necessary: For critical data sets or specific allocation requirements, explicitly specify EATTR=OPT or EATTR=NO in JCL or IDCAMS to override system defaults and ensure the desired behavior.
Monitor EAV and Extended Format Usage: Regularly monitor the allocation and performance of data sets using EATTR=OPT on EAVs or in extended format to ensure optimal configuration and resource utilization.
Consider Performance Gains: Leverage extended format data sets with striping for I/O-intensive applications, but plan carefully to distribute I/O across appropriate devices for maximum benefit.