DFSMS components and SMS constructs
DFSMS is the family of z/OS components that decides where datasets live, how long they are kept and how they are backed up. The Storage Management Subsystem (SMS) applies site policy automatically through classes, storage groups and ACS routines, so users do not have to pick disk volumes themselves.
Why storage management exists
A large z/OS system may have thousands of disk volumes, tens of thousands of tape cartridges and millions of datasets. In the early days, every job had to name the volume its new dataset should go on, and every team kept its own rules for backup and clean-up. That did not scale. DFSMS (Data Facility Storage Management Subsystem) moves those decisions out of individual jobs and into central policy owned by the storage administrators.
The idea is simple: a user asks for a dataset; the system decides what shape it gets, how well it should perform, how it is looked after and which pool of volumes it lands in. If the policy changes, every new dataset follows the new rules without anyone editing JCL.
The DFSMS components
| Component | What it does | You meet it when |
|---|---|---|
| DFSMSdfp | The base: allocation, catalogs, VTOCs, access methods, and the SMS policy engine itself | Any dataset is created, opened or catalogued |
| DFSMSdss | Copies, dumps, restores, moves and defragments data at dataset or volume level (program ADRDSSU) | Volume migrations, full-volume dumps, bulk copies |
| DFSMShsm | Hierarchical storage management: migrates unused data to cheaper storage, recalls it on demand, takes backups | A dataset shows as migrated, or you need yesterday's copy |
| DFSMSrmm | Removable media manager: tracks tape volumes, their contents, retention and scratch status | Tape retention, vaulting and scratch pools |
| DFSMStvs | Transactional VSAM: lets batch share VSAM RLS data with commit and backout | Batch updates VSAM files that CICS also uses |
dfp is part of the base operating system. dss, hsm, rmm and tvs are optional, separately priced features, so a given site may use another vendor's product in some roles, for example Broadcom CA 1 instead of DFSMSrmm for tape management.
The four SMS constructs
SMS describes policy with three classes and one group. Each is a named definition created by the storage team, usually through ISMF (the Interactive Storage Management Facility, an ISPF dialog).
Storage groups come in types. The ones you will hear about most are pool groups (ordinary disk volumes), tape groups (tape libraries), VIO (temporary datasets held in memory-backed paging space) and dummy groups (used for special cases such as handling old JCL that names specific volumes). Each pool group has a high threshold and low threshold: the high value steers new allocations away from volumes that are filling up, and DFSMShsm uses both when deciding how much data to migrate.
ACS routines: policy as code
ACS routines (Automatic Class Selection) are short programs, written in a simple filtering language, that run when a new dataset is allocated. They look at facts such as the dataset name, its high-level qualifier, the job name, the requested size and the environment, then assign the constructs in a fixed order.
PROC STORCLASFILTLIST PRODDB INCLUDE(PROD.DB2.**)WHEN (&DSN = &PRODDB)SET &STORCLAS = 'SCFAST'OTHERWISE SET &STORCLAS = 'SCSTD'The routines and the construct definitions are kept in a Source Control Data Set (SCDS). After the storage team edits them, they translate and validate the routines, then activate the SCDS, which copies it into the Active Control Data Set (ACDS) that every system in the sysplex uses. A COMMDS (communications dataset) keeps the systems in step. Activation can be done from ISMF or with the SETSMS SCDS(dsname) operator command, and is always a change-controlled action.
Rules worth remembering
- SMS-managed datasets must be catalogued; you find them by name, never by volume.
- Users normally should not code VOL=SER for SMS-managed new datasets; the storage group decides.
- Changing a construct definition affects existing datasets that use it (for example a new expiry rule), so changes need review.
- Many problems that look like JCL errors, such as an unexpected block size or a dataset landing on the wrong pool, trace back to ACS logic.
Common mistakes
For SMS-managed data the storage group chooses the volume. Unless the storage class allows guaranteed space, coding VOL=SER either gets ignored or fails. Let SMS place the data and refer to it by its catalogued name.
ACS routines can override what the JCL asks for. Check the dataset's actual constructs in ISPF 3.4 or with LISTCAT before assuming.
One wrong WHEN clause can send production data to the wrong pool or make it non-SMS-managed. ACS changes need testing (ISMF has a test facility) and change control.
What you will see at work
- Developers mostly notice SMS when a new dataset gets attributes they did not expect; the storage team can explain which ACS rule fired.
- Storage administrators own the SCDS and activate policy changes during agreed windows.
- Requests such as 'keep this dataset for seven years' or 'stop migrating these files' are management class questions.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.