ACT System Managed Storage (SMS) Accounting
One of the major enhancements incorporated in IBM's z/OS operating system is the logical implementation of System Managed Storage (SMS). By design, SMS isolates the end user from the physical implementation of the storage hierarchy. Because storage chargeback rates have typically been based on device type (DASD or tape) and quantity, often expressed in device-dependent terms (for example, 3380 track-days), SMS necessitates a major redesign of storage rate structures. Even more revolutionary, SMS changes the orientation of auxiliary storage management from the physical volume to explicit performance and availability criteria. This further changes the design of storage-cost recovery algorithms and the underlying methods by which the unit cost of storage is calculated
micsrm140
One of the major enhancements incorporated in IBM's z/OS operating system is the logical implementation of System Managed Storage (SMS). By design, SMS isolates the end user from the physical implementation of the storage hierarchy. Because storage chargeback rates have typically been based on device type (DASD or tape) and quantity, often expressed in device-dependent terms (for example, 3380 track-days), SMS necessitates a major redesign of storage rate structures. Even more revolutionary, SMS changes the orientation of auxiliary storage management from the physical volume to explicit performance and availability criteria. This further changes the design of storage-cost recovery algorithms and the underlying methods by which the unit cost of storage is calculated
For IS accounting, you must develop an effective method of directly charging for system-managed storage that does not depend on physical device-related characteristics. Furthermore, this method must be adaptable to auxiliary storage installations consisting of mixtures of diverse technologies (for example, conventional magnetic DASD and optical DASD) and implementations (for example, conventional DASD strings and DASD arrays). Your charging method must reflect the differences in the actual cost of these technologies while remaining independent of both the device and the technology. Otherwise, IS end users would have no reason to support the capital investments necessary to modernize.
Storage Hierarchies
Modern computer systems implement storage in the form of a hierarchy in which each tier has a different ratio of performance to cost. At the top of the hierarchy is the high-speed buffer; it offers the lowest access time but is so expensive that it cannot be very large given practical economic constraints. The next level of the hierarchy is main storage, followed by expanded storage, controller cache, DASD, and tape. Each of these levels trades off access speed for reduced cost.
The objective of this hierarchical structure is to provide a total performance level for the entire hierarchy nearly equal to that of the highest performance level at a cost close to that of the lowest performance level.
The lower tiers of the hierarchy, DASD and tape, are managed on a data set-by-data set basis, in an SMS environment, by DFSMS.
Data Set Placement
The primary consideration when placing a data set is usually the amount of space it requires. Because of the economic relationship between the layers of the storage hierarchy, the larger a data set is, the greater the incentive to place it at a lower hierarchical level to minimize storage costs.
The second consideration is frequency of access. If a data set is accessed frequently, the time required to mount a tape volume upon which it resides may become a significant portion of the total processing time associated with the data set. This is especially true if the data set is relatively small, because the processing time for a small amount of data will typically be correspondingly short.
Considered together, data set size and frequency of access determine the optimum media for a great many data sets. Large, infrequently used data sets belong on tape while small, frequently used data sets belong on DASD. In between these two boundaries lies a "gray area" in which additional considerations determine where the data set should be placed.
The third consideration for data set placement is the type of access. Tape, being a sequential medium, is poorly suited to data with random access patterns. Also, it provides little or no capability for inserting records into existing databases. Therefore, it is seldom a choice for IMS or DB2 data databases, regardless of how large they are or how infrequently they are accessed.
SMS Concepts and Constructs
In a pre-SMS environment, data sets are allocated by storage users (application programs, TSO users, storage managers, etc.) on specific physical devices and possessing specific physical characteristics defined by the storage user (space required, method of allocation, logical record length, block size, retention, expiration action, etc.). In an SMS environment, data sets to be allocated are defined as having certain characteristics. These classes of characteristics are then mapped by the SMS components to logical pools of storage that is in turn mapped onto the physical storage hierarchy.
Data sets are assigned to storage groups based on the data's characteristics and storage requirements (performance, availability, etc.). These characteristics and requirements are divided into three classifications:
Data Class
Specifies many of the characteristics of the data such as record format, logical record length, etc.
Management Class
Specifies data management requirements such as length of retention, backup requirements, and disposition of the data set upon expiration.
Storage Class
Specifies performance and availability criteria.
By assigning a new data set to a specific management and storage class, the user defines the storage support requirements for the data. SMS can then map the request into the storage group that is best suited to meet those requirements. Subsequently, the physical placement of the data set can be further optimized as storage demands change or as different physical devices are added to the storage pool.
Life Cycle Management With SMS
In manual storage management schemes, data is generally either active or archived. More often than not, archival of data (both onsite or offsite backup) is treated as an overhead of active data storage. Therefore, the unit cost of storage is simply computed as the fully-burdened cost of the physical storage (per unit of time) divided by the amount of available storage.
In an SMS environment, a data set may migrate from primary storage to secondary storage to archival storage during its life cycle. Therefore, the average amount of time a data set of a given management and storage class resides on each type of storage must be determined and the cost of the primary, secondary, and inactive storage must be computed individually and summarized together to arrive at the actual unit-cost of system managed storage.
Strategies for System Managed Storage Accounting
SMS technology requires a change from a device-dependent (for example, 3380 track-day) accounting algorithm to one based on space-time (for example, Megabyte-Hrs). Since SMS utilizes a class structure based on performance, availability, and data management requirements that were largely implicit in device selection, it seems logical to use these classifications as the basis for storage charging. They provide a basis for implementing a class-of-service algorithm that is equitable, easily managed by IS, and easily understood by the end user.
(Class-of-service charging schemes are widely utilized throughout service industries. For instance, the U.S. Postal Service offers a range of service classes, from overnight delivery to third class bulk rate. The major distinction between these classes is the speed with which the item arrives at its destination. These postage classes are analogous to SMS storage classes that determine how rapidly data may be accessed.)
In particular, SMS Storage Class defines service-level thresholds for performance and availability. These considerations largely determine the device type, cached versus non-cached, channel and control unit utilizations, etc., required by the data. These factors determine the direct cost of the storage.
SMS Management Class defines the retention, backup and disposition requirements. These factors determine the indirect cost of the data storage.
Taken together, storage and management class imply both the performance cost and the support cost of a unit of data stored. This forms the basis for a class-of-service based charging algorithm as follows:
Data set charge = megabyte hours * Storage Class rate + megabyte hours * Management Class rate
Refer to DASD Accounting Features and Implementing for information about how to implement this algorithm at your installation.