Defining Storage Groups

When managing non-system-managed DASD volumes, you view and maintain them as individual devices. If you have too many critical data sets on a volume, you have to spread the data sets across other volumes to remove I/O bottlenecks. If you are allocating data sets manually, your volume use might not be optimal. Some volumes containing critical data sets might be under-used. Other volumes with lower activity data sets might be overpopulated and require extra storage administrator attention to ensure that space is preserved for new data set allocations and extensions. In these and other instances, you have to work on individual volumes to solve your problems.

SMS simplifies the management of DASD, mountable optical volumes, and tape volumes by pooling them together in storage groups. This chapter describes storage groups and shows you how to define them using the ISMF Storage Group Application.

Understanding Storage Groups

Storage groups represent the physical storage managed by SMS. This storage can be collections of DASD volumes, volumes in tape libraries, optical devices, or virtual input/output (VIO) storage. A storage group, used with storage classes, separates the logical requirements of accessing data from the physical requirements to store the data. You can use storage group attributes to specify how the system should manage the storage group. You use the storage group ACS routine to assign a new data set or object to a storage group. You can assign multiple candidate storage groups, in which case the system chooses a specific storage group from your list. Storage group definitions are not apparent to users. Only you, as storage administrator, can define, alter, or display storage group definitions.

A storage group can be VIO, dummy, pool, object, object backup, or tape. VIO storage groups are not associated with volumes. Dummy storage groups are associated with non-existent volumes. (For an explanation of these storage group types, see topic 4.4.) When defining pool storage groups, you must ensure that the actual, physical paths connecting systems to DASD volumes match the desired logical paths specified in the storage group definitions. Merely establishing a physical connection from a system to a DASD volume does not provide access. Within the storage group definition, you must specify which systems have access to which storage groups, and which storage groups have access to which DASD volumes. Likewise, merely defining a system to have access to a DASD volume does not establish a physical connection. You need to ensure that the physical connection exists.

For tape storage groups, one or more tape libraries (and not volumes) are associated with them. Connectivity is defined at both library level or storage group level. If a storage group is connected to certain systems, then any libraries associated with that storage group must be connected to the same systems. Scratch volumes are added to storage groups when they are used. Private volumes may be added when they are entered in a library. Private volumes are removed from a storage group and returned to the common scratch pool when they are returned to scratch status.

DASD Storage Groups

When you define a pool storage group, you specify the volume serial numbers of the DASD volumes you are including in the storage group rather than their physical addresses. Each DASD volume in a storage group must contain a VSAM volume data set (VVDS) and an indexed volume table of contents (VTOC). The VVDS is automatically created after allocation of the first system-managed data set on a volume, if the VVDS is not already defined.

Two storage groups cannot share a DASD volume. You must define an entire volume to a single pool storage group. Also, a data set can only reside in one pool storage group. A data set can span volumes within a single pool storage group, but it cannot span volumes belonging to several pool storage groups. For VSAM data sets, the entire sphere (base cluster and all alternate indexes) must be in the same storage group.

Although not required, we recommend that you define pool storage groups so that they only contain devices of the same geometry. The device geometry is the track size and number of tracks per cylinder for the device.

By defining pool storage groups so that the device geometry is the same for all volumes in the storage group, you can ensure that volumes of the same geometry are available when multivolume data sets need to extend to new volumes.

For example, if you have 3380 and 3390 devices, you should define at least two storage groups: one containing 3380 devices, and another containing 3390 devices.

Because 3390 devices in 3380 track compatibility mode are geometrically the same as 3380 devices, you can combine these devices in a single storage group. Because the 3390 devices are in 3380 track compatibility mode, the access methods see them as 3380 devices.

Although you should separate devices according to geometry, you do not need to separate them according to capacity. For example, you can combine all models of the 3390 into a single storage group. The only effect the different capacities has is on volume thresholds. See MVS/ESA SML: Managing Storage Groups for information on selecting appropriate threshold levels.

Devices of the same geometry can have different performance characteristics. These devices coexist in the same storage group, and enhanced volume selection for SMS will manage data set placement accordingly. With enhanced volume selection, even devices with vastly different performance characteristics (like the IBM 3390 Model 3 and the IBM 3995 Model 153) can reside in the same storage group. Note that the 3995-153 does have a non-zero initial access response time. See "Defining Initial Access Response Seconds" in topic 6.4.5 with help in determining data set placement. >

Defining Management Classes

DFSMShsm manages non-SMS data sets at the volume level, applying the management criteria to all data sets on a given volume. SMS automates the management of storage at the data set level by introducing management classes. When assigned to data sets, management classes replace and expand attributes that otherwise would be specified on JCL DD statements, IDCAMS DEFINE commands, and DFSMShsm commands. When assigned to objects, OAM uses a subset of the management class attributes and the OSMC class transition attributes to manage objects. This chapter describes management classes and shows you how to define them using the Management Class application of ISMF.

With the introduction of the Concurrent Copy COPY TECHNIQUE attribute, the Storage Administrator has the option of specifying whether a Systems-Managed backup process called Concurrent Copy should be used for data sets to enhance system availability during data set backup and aggregate backup processing. Data Set Alter can be used to alter a Management Class so data sets can use the Concurrent Copy technique during backup processing. The Storage Administrator has the option of specifying whether the Concurrent Copy process is required, preferred, or discouraged. The COPY TECHNIQUE attribute is related to the Backup and Aggregate Backup components of Management Class. A COPY TECHNIQUE field exists for each of the Backup and Aggregate Backup components. These fields appear on the Management Class list, display, define/alter, view, and sort panels.

Understanding Management Classes

A management class is a list of data set migration, backup and retention attribute values. Management class also includes object expiration criteria, object backup requirements, and class transition criteria for management of objects. Management Class is not used for tape datasets. DFSMShsm uses the attributes of the management class associated with a data set to manage storage. When you assign a management class to a data set, SMS places the management class name in both the basic catalog structure (BCS) and the VSAM volume data sets (VVDS) catalog entries of the data set. Management class is optional for system-managed data sets and does not apply to non-managed data sets.

If you alter a management class definition, SMS applies the changes to any new data sets or objects after you activate the changed configuration. SMS also applies the changes to any previously allocated data sets or objects, beginning with their next scheduled management cycle (such as daily space management or backup).

Default Management Class: For data sets, you can specify a default management class in an SCDS. DFSMShsm applies the default management class to all system-managed data sets that do not already have a management class. Unlike the data sets that you have already assigned a management class, the catalog entries of these data sets do not contain a management class name. For objects, the default management class is defined in the catalog entry for the object collection to which the objects belong. The default management class is assigned by the management class ACS routine when the first object is stored in the collection.

OAM Management Classes: OAM uses some attributes in the management class associated with the object to manage the object. Class transition attributes allow OAM to change the way an object is managed based on its age, its usage, or a predefined periodic function. A class transition is a change in the object's management class or storage class when an event occurs which brings about a change in an object's management criteria or service level. Class transitions occur during an OSMC storage management cycle. Objects requiring class transition use the ACS routines to determine if they should be managed using a different management class or placed at a different level of the storage hierarchy according to a new storage class.

OAM uses the backup attributes of the management class definition to initiate the writing of an optical backup copy of an object. This copy might be made during the first storage management cycle after the object has been stored and a management class with backup attributes has been assigned to the object.

Retention attributes determine the OAM action for object expiration. An object can expire automatically based on its age, its usage, or a specific date derived from its management class and an object-specific retention period, if provided. OSMC deletes expired objects from the directory automatically during the storage management cycle with the approval of the auto-delete installation-wide exit.

Describing Management Classes

A management class definition contains both descriptive and storage-related information. To identify and refer to your management classes, you assign each one a unique name that contains from one to eight alphanumeric characters. Each management class definition maintains an owner ID that identifies the storage administrator who originally created or last modified the management class. The owner ID is a MVS userid on the ISMF Management Class List in column 19--LAST MODIFIED USERID. Also, each management class contains an optional 120 character description field for describing its contents.

When attempting to improve performance without SMS, you place important and critical data sets on selected storage devices. If you have data sets that consistently require short response times, you place them on DASD volumes that have low I/O rates or that are connected to cache storage controllers. If you have data sets that require continuous availability, you place duplicate copies of them on other DASD volumes. SMS separates data set performance objectives and availability from physical storage by introducing storage classes. This chapter describes storage classes and shows you how to define them using the Storage Class application of ISMF.

With the exception of tape datasets, a dataset is system-managed if it has a storage class. When you assign a storage class to a data set, SMS places the storage class name in both the BCS and the VVDS catalog entries of the data set. Only you, as a storage administrator, can define or alter the storage classes for an SMS complex. End users cannot override the storage classes selected for a data set by the ACS routines.

Tape datasets can be assigned a storage class, however they are not SMS managed. Only tape volumes are SMS managed. Therefore, none of the storage class attributes apply to tape data sets. Since tape datasets are not SMS managed, they do not have to be cataloged, however, the SMS information (data class, storage class, and management class) is not saved in the catalog even if you do catalog the data set. Tape datasets with a storage class can be directed to an SMS managed tape volume via the storage group ACS routine.

Existing and new user applications can also take advantage of sequential data striping for batch processing. Striping should be completely transparent to the application. A new Storage Class attribute SUSTAINED DATA RATE is defined for sequential data striping. The SUSTAINED DATA RATE, in combination with the device transfer rate, is used by the system to derive the number of stripes (maximum of 16) that an extended sequential data set may have.

Note: Depending on the number of eligible volumes in the selected candidate storage groups, the actual number of stripes allocated to a data set may be less than the derived target number of stripes. The number of stripes is the number of volumes on which the data set is allocated. This attribute is available on the Storage Class list, display, define/alter, view, and sort panels. Also see DFSMS/MVS Version 1 Release 2 Using Data Sets for more detailed information on using SMS in assigning storage classes that specify extended sequential data sets.

With the introduction of the Concurrent Copy ACCESSIBILITY attribute, the Storage Administrator has the option of specifying whether allocation to a volume which supports Concurrent Copy is required, preferred, or discouraged. Data Set Alter can be used to alter a Storage Class so that data sets can be allocated on Concurrent Copy-capable volumes, a 3390 DASD connected through a 3990 Storage Control unit with Extended Platform. This attribute appears on the Storage Class list, display, define/alter, view, and sort panels.

Understanding Storage Classes

A storage class is a list of performance objectives and availability requirements. Each storage class represents a list of services that are available to data sets and objects having similar access requirements. A storage class does not represent any physical storage, but rather, provides the criteria that SMS uses in determining an appropriate location to place a data set or object.

With regard to performance objectives, SMS attempts to select a location that meets or exceeds the specified objective, but SMS does not guarantee response time. If no location satisfies the performance objective, then SMS makes an attempt to find a location that most closely matches the specified objective.

For data sets, if no location comes sufficiently close to matching the specified objective, SMS selects the volume with the most available space. The location selected will be on a DASD or tape volume, for data sets, or in an object storage hierarchy, for objects.

When allocating data sets without SMS, end users need to specify many data set attributes. If they have many data sets with similar allocation requirements, they did much copying or repetitive typing. SMS simplifies the allocation of data sets by introducing data classes.

This chapter describes data classes and shows you how to define them using the Data Class application of ISMF.

Understanding Data Classes

A data class is a list of data set allocation attributes and their values. You cannot assign a data class to an object. When end users allocate a data set and refer to a data class either explicitly (for example, through JCL) or implicitly (through ACS routines), SMS allocates the data set using the attribute values of its associated data class. For data class attributes, explicit specifications by end users override any parameters derived from the data class ACS routine. If SMS is active, a data class can be assigned to any data set. For data sets that are not SMS managed, the system uses the allocation attribute values of the data class, but it does not save the data class name anywhere.

Not all attributes apply to every data set organization. When SMS allocates a data set, it uses only those data class attributes that have meaning for the given data set organization. SMS saves the data class name for each SMS-managed data set. The actual data class definitions reside in the SCDS. If you alter a data class definition, SMS applies the changes to any new data sets that use the data class after you activate the changed configuration. However, SMS does not retroactively apply your changes to previously allocated data sets.

Describing Data Classes

A data class definition contains identification and allocation information. To identify and refer to your data classes, you assign each one a unique name that contains from one to eight alphanumeric characters. Each data class maintains an owner ID that identifies the storage administrator who originally created or last modified the data class. The owner ID can be viewed on the Data Class List panel. Also, each data class contains an optional 120 character description field for describing its contents.

The data class allocation attributes match the keywords that you use to allocate data sets. The attributes contain space-related, access-related, and organizational information that you typically find on JCL DD statements, TSO/E ALLOCATE commands, access method services DEFINE commands, dynamic allocation requests, and ISPF/PDF panels.

Planning Data Classes

You should create a data class based on service level agreements. For example, all data sets having a low-level qualifier of LIST, LISTING, OUTLIST, or LINKLIST probably belong to the same data class, because they are typical work data sets having similar allocation characteristics.

Before you actually define any data classes, gather information about the common types of data sets in your installation. You also need to determine if only the data class ACS routine can assign data classes to data sets, if end users can assign data classes to data sets, or if you want a combination of these two policies. If you intend to have only the data class ACS routine assign data classes, you need to develop methods to identify the data in your installation. However, if you allow only the data class ACS routine to assign data classes, you should be aware that users will need to override some data class attributes. For example, you will probably not want to code one data class for each possible amount of space that users will need. Finally, you need to identify the space requirements for some commonly used data sets.

By gathering useful installation information, you can relieve your end users from specifying all of the allocation attributes on allocation requests. They can use the data class that most closely matches their needs and explicitly change the few attributes that are unique to their data sets.

This chapter provides General-use Programming Interface and Associated Guidance Information.

This chapter is intended to help you to define ACS routines. ACS routines can be used to determine the SMS classes and storage groups for data sets and objects in an SMS complex. For storage administrators, ACS routines automate and centralize the process of determining SMS classes and storage groups. ACS routines also help convert data sets to an SMS environment.

An object is assigned to a storage group when it is stored and remains in that storage group throughout its lifetime. Initial storage class and management class might be determined by defaults defined by an ACS routine, or by explicit request which might be overridden by the ACS routines. Storage class and management class assignments might be changed by the OSREQ CHANGE function, or by automatic class transition. The OSREQ CHANGE request causes invocation of ACS routines that might override the requested assignments. During automatic class transition, ACS routines are invoked to determine the new storage class and management class assignments.

This chapter explains how to write ACS routines for an SMS configuration using the Automatic Class Selection application of ISMF.

Understanding ACS Routines

Through ISMF, you can create and maintain as many as four ACS routines in an SCDS, one for each type of SMS class and one for storage groups. After you have activated an SMS configuration, SMS executes the ACS routines for the following operations:

• JCL DD statements (DISP=NEW, DISP=MOD)
  
• Dynamic allocation requests (DISP=NEW, DISP=MOD for a non-existent data set)
  
• DFSMSdss COPY, RESTORE, and CONVERTV commands
  
• DFSMShsm RECALL and RECOVER
  
• Access method services ALLOCATE, DEFINE, and IMPORT commands
  
• OAM processing for STORE, CHANGE, and class transition
  
• Local data set creation by remote application through Distributed FileManager/MVS

As a storage administrator, you write ACS routines using the ACS programming language, a high-level programming language. The language follows a logical, procedural flow of execution that consists mainly of filtering criteria, IF/THEN statements, and SELECT/WHEN statements. Using these relational statements, ACS routines determine SMS classes and storage groups according to allocation parameters, data set sizes, object or dataset names and other variables.

All allocations which are directed to units which are neither tape nor DASD should be excluded from SMS management. This can be done by testing for UNIT in the storage class routine and ensuring that the storage class is set to NULL in these cases.

Ensuring that no storage class is assigned for such allocations will avoid potential errors with allocations that require specific types of units. For example, assigning a storage class to a VTAM channel-to-channel (CTC) adaptor allocation will result in sense errors when VTAM attempts to use the CTC.

Note: For system-managed data sets, the storage group is required because there is no way to explicitly specify storage groups. The other routines are optional. For objects, the storage group, storage class and management class ACS routines are required. For tape, the storage group, storage class and data class ACS routines are required.