- z/OS file structures
- DFSMS on z/OS
- Data Class
- Management Class
- Storage Class
- Storage Group
- ACS routines
- z/OS file utilities
- z/OS SMF statistics
- z/OS RMF reporting
Storage classes perform several functions. They decide if data should be SMS managed or not, they decide what level of performance a file should have, and they decide if you can override SMS and place data on specific volumes. A storage class can also define whether or not a dataset can use concurrent copy for instant backups, if VSAM files can use RLS in the coupling facility and what the requirements are for PAV volumes.
SMS places the storage class name in both the BCS and the VVDS catalog entries of the data set. While tape volumes can be SMS managed, the tape data sets are not, even though you can assign them a storage class. Therefore, none of the storage class attributes apply to tape data sets.
If you don't want a file to be SMS managed, then you simply arrange for it to get a null storage class as in the example below.
IF &DSN=SYS1.* THEN DO
SET &STORCLAS = ''
There are occasions when you, as a storage administrator, want to a file to be non-SMS managed. Systems Programmers probably need that access too,
but you don't want everyone to be able to do this.
There is an easy way to control this. Put all the dataset patterns that you never want SMS managed into an NONSMS filtlist, then advise trusted users that they can specify a 'NONSMS' storage class for other datasets they want to allocate outside SMS. Then code at the front of the storclas ACS routine
IF &DSN = &NONSMS THEN SET &STORCLAS = ''
IF &STORCLAS = 'NONSMS' THEN SET &STORCLAS = ''
The first line checks file names against a non-SMS list, the second line checks for a user specifically requesting a non-SMS storage class. N.B. you do not define a NONSMS storage class in ISMF to deal with this, the NONSMS storage class is just a dummy name which is changed to null by the ACS routine. If you want to ensure that only authorised users can make a file non-SMS, then just combine this with an authorised user list as below.
This is the other side of the coin. You want a dataset to be SMS managed, but you want to place it onto a specific disk. A good example, is the FDRABR
initialisation dataset, which must go on the correct disk. You do this by using an SMS construct called 'guaranteed space'.
When you define a storage class in ISMF, you will see a parameter
Guaranteed Space . . . . . . . . . N
You change the pre filled 'N' to a 'Y', and SMS will not guarantee you any space, but it will guarantee to give you the volume you ask for. Its your responsibility to check that the space is there.
This is a powerful facility which lets you override all SMS control. I suggest you restrict it to a controlled set of users, using the following.
Define a storage class called something like GSPACE, which has the guaranteed space attribute set to 'Y', and define a Filtlist which contains explicit users who can override SMS, or pattern masks of users that can override SMS, if you RACF naming standards let you do this.
If you specify a storclass of 'GSPACE', and if you are contained in the list of authorised users, you will get the volume you asked for, otherwise, you drop down to a default value.
The CF Cache Set Name parameter is used for VSAM record level sharing. To enable this, you need to enter a valid cache set name, as defined in the DFSMS base configuration, and then provided the LPAR has connectivity to the coupling facility, datasets that are assigned this storage class are eligible for VSAM RLS.
CF Direct Weight and CF Sequential Weight parameters also exist where you can define what weighting, or how important these datasets are. However DFSMS will always ignore anything you specify here and allocate a default weighting of '6' to everything, so this parameter is best left blank.
The 'Multi-Tiered SG' parameter is used so that if you specify in your ACS routines that files can be allocated into one of a list of storage groups, then DFSMS will honour the order of the groups in your list and try to use the earlier ones first. This parameter defaults to 'N' which means DFSMS will pick the pool that it thinks is best. Change this to 'Y' to get DFSMS to follow your preference order.
The Parallel Access Volume page explains how PAV works. If you disks are not all PAV capable, you can use the 'Parallel Access Volume Capability' parameter to decide what the requirements are for datasets assigned to this storage class. You specify 'R' for required, 'P' for preferred, 'S' for standard., and 'N' for no preference. The default is 'N'.
This relates to a set of attributes in the SMS storage class ISMF definition
These definitions are largely ignored for modern DASD, except that IBM ESS DASD may keep data cache resident for longer, if it has a low response
There is another storage class attribute which can help performance, striping. Striping means taking a file, and arranging for it to be spread over several logical disks, so parts of it can be accessed concurrently. This facility has been pretty much overtaken by PAV aliases and RAID disk . However, if you want to implement it, you do this by defining a striping storage class, with a number between 1 and 999 set for SUSTAINED DATA RATE.
z/OS 2.1 introduced zHyperlink, which can dramatically reduce latency by interconnecting the z14 Central processor complex directly to the I/O bays in the IBM DS8880.
This is accomplished by installing zHyperLink adapters on the z/OS host and IBM DS8880 family hardware, and connecting the hardware by zHyperLink cables. This reduces the I/O response time by up to 10 times compared to zHPF, because the dispatching, interrupt handling, CPU queue time, and CPU cache reload activities are no longer necessary.
In z/OS V2R3, SMS introduces the ability to specify whether data sets associated with a storage class are eligible to use zHyperLinks for reading and writing. Quite a few z/OS commands and DS8000 microcode upgrades are needed to enable zHyperlink. Check out the IBM manuals for details, especially the relevant Redbook. Here, all we are concerned with is the SMS change, which relates to 2 new parameters in the Storage Class. These are
zHyperLink Eligible for read. . . Y (Y or N)
zHyperLink Eligible for write . . N (Y or N)
You might not need too many storage classes. One for guaranteed space, one for datasets which need to stay cache resident as long as possible, one for concurrent copy files one for SMS managed tape and a default class for everything else. You may want to more for striping, zHyperlink and PAV alias management.
Another option I've seen is to have a direct, name for name match between storage classes and storage groups. The logic behind this is that the storage groups determine the physical hardware, and so the type of performance in which case why not just match storage groups to storage classes. A certain benefit is that the storgrp ACS routine will be very simple.
back to top