ACSID - Automatic Class Selection ID

Enhanced Definition

In IBM z/OS, an ACSID (Automatic Class Selection ID) is a numeric identifier (0-255) assigned to a specific set of **Storage Management Subsystem (SMS)** Automatic Class Selection routines. It allows system administrators to define and manage multiple, distinct sets of SMS policy rules, which are then selectively activated to control dataset allocation and storage characteristics.

Key Characteristics

- Numeric Identifier: A single-byte value ranging from 0 to 255, uniquely identifying a specific set of ACS routines within an SMS configuration.
- Policy Activation: Used to activate a particular set of ACS routines (Data Class, Storage Class, Management Class, Storage Group) at a given time, often during system initialization or via operator commands.
- Dynamic Switching: Enables the dynamic switching between different storage policies without requiring an IPL (Initial Program Load) or extensive system reconfigurations, facilitating maintenance or policy changes.
- Version Control: Provides a mechanism to manage different versions or scenarios of storage policies, enabling testing of new policies before full deployment or quick rollback to previous versions.
- SMS Integration: Integral to the functioning of SMS, as it dictates which set of rules will be applied when new datasets are allocated, influencing their placement, performance, and availability.

Use Cases

- Policy Testing: Activating a specific ACSID containing new or modified ACS routines for testing purposes on a subset of workloads or during off-peak hours before global implementation.
- Disaster Recovery: Switching to an ACSID configured for disaster recovery scenarios, which might prioritize specific storage groups or data classes suitable for recovery operations.
- Workload Isolation: Using different ACSIDs to apply distinct storage policies for different applications or departments, ensuring their data adheres to specific performance, availability, or retention requirements.
- Maintenance Windows: Temporarily activating an ACSID that directs new allocations to specific storage resources during maintenance periods for primary storage, preventing disruption.
- Seasonal Workloads: Employing different ACSIDs to manage storage for workloads with varying demands throughout the year, optimizing resource utilization based on peak or off-peak seasons.

Related Concepts

The ACSID is fundamental to SMS (Storage Management Subsystem), acting as the primary mechanism to select and activate a specific set of ACS routines (Automatic Class Selection routines). These routines (Data Class, Storage Class, Management Class, Storage Group) are REXX or COBOL programs that determine the storage attributes for new datasets. By selecting an ACSID, an administrator effectively chooses which set of these routines will be executed, thereby dictating how data is allocated, managed, and eventually migrated or deleted according to the defined storage policies.

Best Practices:

Documentation: Thoroughly document each ACSID and the specific purpose and version of the ACS routines it points to, including change logs and activation procedures.
Version Control: Treat ACSIDs as a form of version control for SMS policies, maintaining a clear strategy for activating, testing, and rolling back different policy sets.
Testing Environments: Always test new ACSIDs and their associated routines in a non-production environment before deploying them to production to prevent unintended storage allocations.
Granular Control: Use ACSIDs to provide granular control over storage policies, allowing for flexible and responsive management of diverse workload requirements.
Operator Procedures: Establish clear operational procedures for switching ACSIDs, including necessary commands (e.g., SET SMS ACSID(xx)) and verification steps to ensure the correct policy is active.