HSM Components

The main HSM components are illustrated below.

The white boxes are the data functions, the yellow ellipses are the control datasets, the blue boxes are the data stores, and the green boxes are the recovery logs and trace datasets.

Migration

Backup & Migration are the two main functions of HSM.

HSM recognises data in three places. ML0 (Migration level 0) is the on-line data that is accessed by applications and users. Data is usually moved to ML1 (Migration level 1) first, according to SMS management class rules. ML1 is a dedicated pool of disks, which are non-SMS managed. The data is compressed. The minimum size a dataset can be is about 53K (assuming 3390 track geometry). Small datasets could be archived to ML1, but still use the same space, so small datasets are held as records in Small Data Set Packing datasets (SDSPs). These are standard KSDS VSAM files.
To use small dataset packing, you have to tell DFHSM how big a small dataset is. You need an entry in your ARCCMDxx dataset like

SETSYS SMALLDATASETPACKING(KB(160))

As a guide, a single track record using half track blocking, and getting 3:1 compression will use about 160KB on ML1. If all these assumptions are correct for your site, then 160KB is a reasonable cutoff point, as anything smaller would not occupy a whole track.

If a dataset continues to be unused, it will eventually be migrated off to ML2 (migration level 2), which is usually high capacity cartridge. Large datasets are often migrated straight off to ML2.
Migrated datasets are given a special catalog entry, with a volser of MIGRAT, to indicate that the dataset is migrated. The MCDS (Migration Control Data Set) keeps a record of what has been migrated, and where the migrated data is held. If you try to access a migrated dataset, it will be automatically recalled back to ML0.

There are three variations of space management

Primary Space Management

To run primary space management you need to issue commands like these

                                         
  DEFINE PRIMARYSPMGMTCYCLE(YNNNYNN) -
   CYCLESTARTDATE(2004/03/01)
   SETSYS PRIMARYSPMGMTSTART(0100 0300)

This means run primary space management on Mondays and Fridays, starting at 01:00. HSM will not start to process any new volumes after 03:00. The reason why it starts on a Monday is because March 1st 2004 was a Monday. You would typically enter this command once when setting up HSM, and then just enter it again if you wanted to change the parameters.

Primary space management does all the space management functions on the primary, or ML0 disks. If allowed by parameters, it will delete temporary and expired datasets, release unused space, then migrate data to ML1 or ML2 as appropriate, until all volumes are below their SMS thresholds.

Secondary Space Management

Secondary space management needs an initial command, similar to primary space management. If you never enter this command, then secondary space management will never run.

  DEFINE SECONDARYSPMGMTCYCLE(YNNNYNN) -
   CYCLESTARTDATE(2004/03/01)
      SETSYS SECONDARYSPMGMTSTART(0030 0200)

Secondary space management basically looks after the ML1 and ML1 archive pools. If the management class criteria are met it moves data from ML1 to ML2, it runs TAPECOPY commands if they are needed and it deletes expired migrated datasets.

Interval Migration

You run interval migration on one LPAR, so for that LPAR you specify

  SETSYS INTERVALMIGRATION
  SETSYS MAXMIGRATIONTASKS(5)

in the ARCCMDxx Parmlib member, and in all other LPARs you specify

                                         
  SETSYS NOINTERVALMIGRATION

Interval migration runs every hour, and checks each volume occupancy against the SMS threshold settings for the volume's storage pool. If the high threshold is exceeded, then DFHSM will migrate eligible datasets until the low threshold is reached or no more data sets are eligible. It will also delete temporary and expired data sets

Automatic Recall

You can restrict the number of recall tasks with the following SETSYS parameter.

 SETSYS MAXRECALLTASKS(n2) TAPEMAXRECALLTASKS(n1)

The tape recall tasks are a subset of the max recall tasks, so n1 must be smaller than n2.

Backup

Data needs to be backed up on a regular basis, incase it is accidentally deleted or corrupted. Hardware failure is very rare these days. HSM can stage backups to ML1, or write them straight to tape. Backups are recorded in the BCDS (Backup Control Data Set). This makes recovery very easy. The OCDS (Offline Control Data Set) keeps a record of all tapes used by HSM, both backup and migration.

To schedule HSM backups to run automatically, you need to add lines like these to your ARCCMDxx member

   SETSYS AUTOBACKUPSTART(0100 0200 0600)
   SETSYS MAXBACKUPTASKS(3)

What this says is that the backups will start between 01:00 and 02:00, and no new volume backups will start after 06:00 Up to three concurrent backup tasks can run on this host. If you are running in a sysplex with several LPARs, its best to run several concurrent backup tasks from a single LPAR, rather than spreading the tasks between LPARS.

Log & PDA files

The CDS files are critical to HSM, so updates to them can be logged. If a CDS fails, it can be recovered from backup, then the log updates applied to get it back to the point of failure. The PDA (Problem Determination) files are trace datasets. The CDS Recovery section explains how the logs can be used to fix CDS errors.

back to top

By entering and using this site, you accept the conditions and limitations of use