- z/OS file structures
- DFSMS on z/OS
- Data Class
- Management Class
- Storage Class
- Storage Group
- ACS routines
- z/OS performance
- z/OS file utilities
- z/OS SMF statistics
- z/OS RMF reporting
Usage of Management classes is optional for SMS-managed data sets and does not apply to non-SMS-managed data sets.
Management classes are used to determine backup and migration requirements. This is a definite area where you can either install a simple system managed by your users, or you can make your life difficult and do it all yourself. There are a lot of Storage Managers out there who are uncomfortable with the concept of letting the users decide what class of service a file gets. However, if you decide not to let your users pick their own management classes, you end up with large filtlists, and complicated logic in the Management Class ACS routine. If you get it wrong, and files are deleted too early, or backups not kept long enough, its YOUR fault. If you supply your users with good documentation and procedures, and they allocate a file with the wrong class, its their fault.
Here's an example of how it could be done.
The 'EXPIRE' fields are set to 'NO LIMIT', which means we are not going to delete this data automatically. 'Primary Days' amd 'Level 1 Days' are used for DFHSM archiving and mean keep a dataset on primary disk for 15 days non-usage, then another 42 days on compressed disk before migrating it off to tape. 'BACKUP FREQUENCY' 1 means back a file up once a day. The '# BACKUPS' parameters relate to how many backups to keep, if the dataset exists online, or if it has been deleted. The main difference between these 3 management classes is the back retention details.
You arrange the ACS routines so that file will get the STANBK management class by default. Users can then modify an existing data set's Management Class by using the IDCAM's 'ALTER' command, on the line of the data set. It is also possible to remove the management class definition from an SMS management class using IDCAMS ALTER as shown in the second example below.
ALTER (/) MGMTCLAS(newname) where (/) = datasetname
ALTER (/) NULLIFY(MGMTCLAS)
For new datasets, a management class can be specified with either the JCL keyword MGMTCLAS=, or by filling in the management class field in ISPF option 3.2
You will need a few special management classes for special files.
The STANML2 class is exactly the same as the STANBK class above, except that when the data is migrated, it goes straight to ML2 (tape). This is usually used for very big files and you would invoke this in your ACS routines with code that looks a bit like
IF (&SIZE < 1000MB) THEN DO
SET &MGMTCLAS = 'STANBK'
SET &MGMTCLAS = 'STANML2'
Generation Data Groups are generally created, then never updated again, so they need special processing. For instance, older files are usually migrated earlier than a normal file would be. The '# GDG on Primary' means how many versions of the GDG do you want to keep on disk. If you set this to '1' as above, then the normal Primary Days parameter is ignored for GDGs and DFSMS will mark all GDGs apart from the most recent one as elligible for migrations. This does not mean just keep the most recent generation on Primary disk, the most recent file will be elligible for migration when the primary days parameter expires.
The other GDG processing option is what to do with rolled off GDGs. If a GDG base is defined with a limit of '10', then the 10 most recent GDG datasets are retained in the catalog as part of that base set. However it is possible for older GDG datasets in the same base to exist, usually because they have been restored. These entries are retained in 'rolled off' status. The action above is to EXPIRE, or delete these files.
You invoke the GDG class with code like
IF (&DSTYPE = 'GDS') THEN DO
SET &MGMTCLAS = 'GDG'
The NOMGMT class is for files that you never want archived or space managed. You probably want to restrict access to this class, and so its probably best managed explicitly from a filtlist. Typically, you would use this for Started Task files.
The management class has a freespace release parameter to cut overallocated files down to size.
Finally, How do the 'backup' fields work? Firstly, these don't apply to all mainframe backup products. Native DFDSS and FDRABR work on a volume basis, and management classes are ignored. If you use DFHSM as your backup product, it will use these classes to decide how long backups are kept.
There are two types of backup, the most recent, or active backup, and older, or inactive backups. A file can have two statuses, online or deleted. If a file is online, the most recent, or active backup is always kept. There's no parameter to control this, that's just the way it is. Retention is controlled by parameters as shown in the table below
|File Online||File Deleted|
|Active Backup||Always Kept||"# backups DS deleted"can be set to '0', which means no backups are kept if the file is deleted|
|Inactive Backup||'# backups DS exists' controls how many backups are retained, 'Retain Days Extra Backup' controls how long inactive backups are kept for||'# backups DS deleted' controls how many backups are retained, 'Retain Days Extra Backup' controls how long inactive backups are kept for|
This is a simplified picture of course. In practice you will need a management class for each type of service that is required by our organisation. Start with the basics, then add others as they are required.
back to top