DFSMShsm, tape and virtual tape
DFSMShsm keeps disk from filling up by moving unused data to cheaper levels and bringing it back automatically when someone needs it. It also takes backups. Tape, now mostly virtual tape, is where long-term and migrated data often ends up.
The storage hierarchy
Not all data deserves fast disk. A month-old report that nobody opens is costing primary disk space every day. DFSMShsm (usually just called HSM) manages data across levels, guided by each dataset's management class.
When a dataset migrates, HSM moves it off primary disk and updates the catalog so the volume shows as MIGRAT (ISPF 3.4 and similar tools show MIGRAT1 or MIGRAT2 to indicate the level). The name still works. When a job or user allocates it, HSM recalls it automatically to primary disk. Recent z/OS releases can also migrate to cloud object storage using Transparent Cloud Tiering, if the site has set it up.
Command - Enter / to select action Message Volume ------------------------------------------------------------------------- PAY.MONTHLY.REPORT.G0041V00 MIGRAT2 PAY.MONTHLY.REPORT.G0042V00 MIGRAT1 PAY.MONTHLY.REPORT.G0043V00 PRD123
Space management cycles
HSM runs scheduled cycles. Times and windows are set by the site, but the shape is the same everywhere.
| Cycle | When | What it does |
|---|---|---|
| Primary space management | Daily, in a defined window | Expires datasets that are due, releases unused allocated space where allowed, and migrates datasets that have not been used for the number of days set in the management class |
| Interval migration | Through the day, typically hourly | Checks volumes above their high threshold and migrates eligible data to bring them back down |
| Secondary space management | Daily | Moves data from ML1 to ML2 when it has aged enough, deletes expired migrated data and tidies HSM records |
| Automatic backup | Daily, in a defined window | Backs up changed datasets whose management class asks for backup, keeping the number of versions specified |
| Automatic dump | As scheduled | Takes full-volume dumps using DFSMSdss for disaster recovery |
HSM keeps its own records in control datasets: the MCDS (migration), BCDS (backup) and OCDS (offline tape), plus a journal. Protecting and backing these up is a core storage-team task; if they are damaged, HSM cannot find what it migrated.
Commands you can use from TSO
HRECALL 'PAY.MONTHLY.REPORT'HMIGRATE 'MY.OLD.DATA'HBACKDS 'MY.SOURCE.PDS'HRECOVER 'MY.SOURCE.PDS' REPLACEHDELETE 'MY.OLD.DATA'Whether you may use these, and with which options, depends on site authorisation. Operators control HSM itself with MODIFY commands against its started task (the task name varies by site), for example to hold or release functions.
Tape and virtual tape
Tape is still important on z/OS for backups, archive data, HSM ML2 and large sequential files. Today most mainframe 'tape' is virtual tape: the system thinks it is writing to tape drives, but the data goes to a disk cache in an appliance, which may later copy it to physical cartridges or replicate it to another site. IBM's TS7700 family is the most common; other vendors offer similar virtual tape or tape-to-cloud solutions.
A tape management system tracks every tape volume: which datasets it holds, how long they must be kept and when the volume can return to scratch. DFSMSrmm is IBM's; Broadcom CA 1 and CA TLMS are also widely used. Without one, a tape with seven-year retention could be overwritten by tonight's batch.
- Writing jobs request a scratch volume.
- The tape manager records the dataset and its expiry.
- Vaulting rules may move the volume, or its copy, off site.
- When everything on it has expired, the volume returns to scratch for reuse.
Common mistakes
A migrated dataset still exists and is still catalogued. Referencing it triggers a recall. Do not recreate it under the same name.
HSM backups follow management class rules and keep a limited number of versions. Regulated or disaster-recovery data needs a deliberate backup and retention design agreed with the storage team.
Jobs that touch many migrated datasets can wait for tape mounts. Recall ahead, or change the management class, rather than accepting a slow critical path.
What you will see at work
- In ISPF 3.4 you will often see MIGRAT next to old datasets; that is normal and recall is automatic.
- Batch support sometimes issues HRECALL before a run that needs old GDG generations, to protect the batch window.
- If a job hangs in allocation, a pending HSM recall or tape mount is one of the first things to check.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.