Defining storage classes

Without SMS, you must place critical data sets on selected storage devices in order to improve performance. For example, 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 can place them on dual copy, RAID volumes, peer-to-peer remote copy (PPRC), or extended remote copy (XRC).

SMS uses storage classes to separate data set performance objectives and availability from physical storage. It also provides attributes for the following:

Sequential data striping for batch processing
Allocation to a volume that supports concurrent copy, SnapShot, or FlashCopy®.
VSAM record-level sharing between different systems with storage classes defined to use the coupling facility (CF).

This topic describes storage classes and shows you how to define them through ISMF.

Restriction: Duplication of Library Volsers: DUPT@SMS is an IBM® reserved name and must not be defined in SCDS by the installation.

With STORCLAS=DUPT@SMS and DISP=OLD and VOL=SER=nnnnnn specified in the JCL, you can access an imported tape outside an automated library for input if you have another tape with the same volser in a system-managed library.

With STORCLASS=DUPT@SMS and DISP=NEW (file sequence > 1) and VOL=SER=nnnnnn specified in the JCL, you can also access a tape outside of an automated tape library for output if you have another tape with the same volser in a system-managed library. Specifying DUPT@SMS indicates that the DISP=NEW request is to be non-system managed. This directs the allocation of the duplicate volume to a stand-alone device. For DISP=NEW (file sequence 1), the assignment of a storage class when the automatic class selection (ACS) routines are run determines if the initial request is system-managed.