Data Set Allocation and Performance

Management Under System Managed Storage1

Dr. H. Pat Artis
Performance Associates, Inc.
72-687 Spyglass Lane
Palm Desert, CA 92260
(760) 346-0310
drpat@[Link]
Abstract: System managed storage (SMS) redefines data set allocation for the MVS operating system and provides new data
set level performance management capabilities that exploit advanced cached control unit functionality. Unfortunately, the
algorithms and measurement data sources that support these DFSMS2 functions are poorly defined in the available
documentation. This tutorial will provide a detailed description of the execution of ACS (Automatic Class Selection) routines,
SRM (System Resources Manager) interface, device selection, volume free space management, inter-system communication,
data set level caching and interfaces with the 3990-3 control unit.
1.0 Introduction
The objective of this tutorial is to provide an overview of how SMS manages data set allocation and data set performance. This
tutorial is the result of extensive research based on a variety of IBM publications, IBM’s SMS customer education materials,
reviews of the non-OCO3 DFP 3.2 and 3.3 code, and experiments conducted by the author under DFP versions 3.1 and 3.2.
While the majority of the statements in this paper are based on available documentation, some aspects of the operation of OCO
code have been inferred or conceptualized by the author based on observation, the parameter lists that are exchanged with
non-OCO modules, or the name of the OCO module. All of these assertions (i.e., opinions and conclusions of the author) are
clearly identified in the text of the tutorial to distinguish them from documented facts. The tutorial also includes a number of
highlighted observations related to performance measurement and management under SMS and to additional facilities that
might be useful in future releases of the products.

MVS ISPF/ISMF

DFP Data Data

Security SORT
Mover Archive

ICKDSF (DFDSS) (DFHSM) (RACF) (DFSORT)

Figure 1. DFSMS Structure

1  1990 Performance Associates, Inc., all rights reserved. No part of this publication may be reproduced, stored in a
retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or
otherwise, without the prior written consent of the copyright owner. Permission is granted to the Computer
Measurement Group to publish this paper in the Proceedings of CMG ’90.
2 MVS, MVS/XA, MVS/ESA, MVS/DFP, DFSMS, DFHSM, RACF, DFSORT, and IBM are all trademarks of the
International Business Machines Corporation.
3 OCO is a term used to refer to IBM’s Object Code Only policy. In the early 1980s, IBM elected not to distribute
critical parts of key products in source code to their customers. This policy was developed by IBM to address a
variety of security, trade secret, and other issues that they perceived in the market place.
The reader should note that the IBM’s SMS product family is defined by a group of four subsystems operating under the control
of DFP, Data Facilities Product as is shown in Figure 1. These four products are:

DFDSS: Data Set Services, IBM’s data mover,[1]

DFHSM:the Hierarchical Storage Manager, IBM’s archive manager,[2]

RACF: the Resource Access Facility, IBM’s security product,[3]

DFSORT: IBM’s sort utility.[4]

In addition to the four major subsystems, the figure also depicts the ISMF and ICKDSF facilities of DFP. ISMF, the Interactive
Storage Management Facility, is a panel driven application for the storage administrator that executes under the TSO ISPF
facility. ICKDSF is the volume initialization and maintenance facility provided by DFP.

2.0 SMS Overview

Figure 2 provides an overview of how data sets are allocated and how data set performance is managed under SMS. The
objective of this tutorial is to explain the facilities depicted in this figure. The reader should note that this figure represents the
author’s conception of SMS rather than a formal product concept that has been introduced by IBM.

To begin this tutorial, we will review the major sections of the figure. While the specific details of the processes introduced
in this overview will not be discussed until later in this tutorial, it is useful to introduce the major functions depicted in the
figure. The upper left hand corner of the figure depicts the execution of the ACS routines. Assuming that the ACS routines
determine that the allocation is to be system managed, then a list of candidate storage groups along with the data set’s service
level requirements is passed to SMS. SMS identifies two lists of volumes for the allocation process. The first list, called the
primary (shown being passed to the SRM in the upper center of the figure) contains all of the volumes in the candidate storage
groups that meet or exceed the service objective for the data set and have adequate free space to service the allocation. The
secondary list (not shown) contains all of the volumes in the candidate storage groups that have adequate free space for the
allocation.

ACS ROUTINES LCU Utilizations

Data Set
DC MC SIO Level
Caching
SRM Volume Selection
3990-3

Primary Target
SC SG Vol List Volume

SMS Controlled Set CASF X 3990-1/2

Allocation Token
IECDSCAN
Performance SMS Read Cache Statistics
Capabilities X 3880-x3
Selected Volume
UCBs Constructs
Storage Group
Volume Lists X 3880-x
IECDPERF Free Space
DADSM
Table
Read Seq Pt from UCB
R/W COMMDS
Write Seq
Read Dir every 15 secs ? PCM
Update Free
Write Dir Allocation
Space Table

COMMDS

SMS MANAGED VOLUMES

Other SMS Systems

Figure 2. DFSMS Overview

Rather than measuring the actual performance of the candidate volumes on an ongoing basis, SMS bases its allocations on the
expected values of the read/write service times for the volumes for a variety of device type and control unit combinations.
These expected service level values are shown in a module referenced by pointers in the UCBs as is shown in the lower left
hand corner of the figure. Furthermore, an ongoing estimate of the free space on each volume is maintained in the SMS address
space. The free space on each volume is calculated when SMS is initialized and is updated every time a new data set or extent
is allocated on a volume. However, the space value maintained in the SMS address space is an ongoing estimate since other
systems that share the volume may allocate data sets that are not known to the other systems that share the volume. To address
this issue, multiple systems synchronize their free space tables every 15 seconds4 by reading and writing the communications
data set (COMMDS) as is depicted in the bottom center of the figure.
After the primary and secondary lists have been constructed, the primary list is passed to the SRM for volume selection as is
shown in the upper center of the figure. The SRM selects the volume based on the instantaneous load measured for each of
the potential LCUs at the time of allocation. If all of the primary volumes fail for some reason, the volume with the greatest
free space is selected from the secondary list. When the data set is allocated, DADSM updates the free space tables in the SMS
address space as is shown on the bottom right hand side of the figure.
For data sets allocated behind 3990-3 control units, the Dynamic Data Set Caching is used to manage each data set’s use of
the cache resource each time the data set is opened. Based on the millisecond response target (MSR) specified for the data set
by its Storage Class, each data set is assigned a status of never, may, or must-cache. These requirements are communicated to
the dynamic caching algorithms via a CASF (Cache Attribute Selection Facility) token that is created for the data set when it
is opened. Briefly, SMS interrogates each 3990 on a periodic basis to determine its cache status. Based on these samples, the
Define Extent channel control words (CCWs) for may-cache and must-cache data sets are modified by a module called
IECDSCAN to dynamically maximize the use of the cache and to improve the performance of may-cache data sets while
attempting to insure the response time of the must-cache data sets.
The remaining sections of this tutorial will elaborate on the brief overview of Figure 2 that has been provided in this section.
3.0 ACS Routine Execution
The first step in allocation of each new data set is the execution of the ACS routines. As input, these routines receive five
types of input variables as well as any suggestions that the user may have made for the data set’s Data, Management, or Storage
Classes in the allocation request as is shown in Figure 3. These variable types are:
Data Set: data set name and physical characteristic information,
Installation: job, step, program, DD name, user group, and account code.
Security:5 the default data class, management class, storage class for the data set as identified by RACF. In addition,
RACF provides information on the application and data set owner to the ACS routines,
Special Purpose: allows the ACS routine to determine the environment under which it was invoked, the mode of the
task being serviced, and the names of any volumes or units suggested in the allocation request passed by the task to
the ACS routines,
Transitional: traditional JCL values (e.g., UNIT and number of volumes) that will be phased out during the installation
of SMS.
As is shown in the figure, the ACS routines return four output variables. These output variables are Data Class, Storage Class,
Management Class, and Storage Group. Other than these four variables, the ACS routines cannot modify or redefine any of
the input variables which they are passed. As such, the ACS are significantly different in scope than the reader/interpreter or
DADSM exits that many installations use today to modify user allocation requests or enforce local DASD standards.
Figure 4 provides an overview of the execution of the ACS routines. Briefly, the ACS routines are coded in a high level
procedural language that is somewhat similar to the TSO CLIST language. These routines are developed, tested, and translated
by the storage administrator during the installation of the SMS product. As was mentioned in the previous paragraph, every
data set allocation is processed by the user provided ACS routines.

4 This is a default value that may be changed by the user.

5 While the author has chosen five types of variables to define the input parameters received by the ACS
routines, IBM’s documentation includes the security variables in the same list as the installation variables. The
author elected to make this distinction based on the new ability to use the RACF 1.8.1 (and above) data set
profile to provide an alternate index for critical data set characteristics or to correct data set naming conventions
in a manner that is transparent to the users of the system.[5,6]
 DATA SET INSTALLATION SECURITY SPEC PURPOSE TRANSITIONAL

&DSN &GROUP &DEF_DATACLAS &ACSENVIR &UNIT

&HLQ &ACCT_JOB &DEF_MGMTCLAS &XMODE &NVOL
&LLQ &ACCT_STEP &DEF_STORCLAS &ALLVOL &MSVGP
&NQUAL &PGM &APPLIC &ANYVOL
&DD
&DSTYPE &DSOWNER
&JOB
&RECORD
&DSORG &USER
&SIZE
&MAXSIZE
&EXPDT
&RETPD

DC MC
ACS
ROUTINES
SC SG

READ/WRITE
&DATACLAS
&STORCLAS
&MGMTCLAS
&STORGRP

Figure 3. ACS Routine Input Variables

The first ACS routine is the data class routine.6 The purpose of the data class routine is to provide prototypes to support data
set allocation. For example, a prototype called SOURCPDS might be used as a model for the allocation of all new programmer
source data sets. The objective of this prototyping process is to eliminate the need for most users to make space allocation
estimates, remember the specific geometric properties of different device types, or select proper blocksizes. The data class
ACS routine has a single output variable called &DATACLAS. The reader should note that a data set need not be assigned a
data class to be managed by SMS.
The second ACS routine is the storage class routine. The storage class routine determines the service level and availability
required to support the data set. The output of the storage class ACS routine is a single output variable called &STORCLAS.
As is depicted in Figure 4, if the ACS routine does not assign a storage class to a data set, then the data set does not fall under
the control of SMS and is then managed by the standard OS allocation routines. If a storage class is assigned, the data set will
be managed by SMS.
The third ACS routine is the management class routine. The management class routine specifies the backup frequency, number
of backup/archive copies, retention period, and other management related aspects for the data set. The output of the management
class ACS routine is a single output variable called &MGMTCLAS. These requirements are passed to DFHSM, on a data set
by data set basis, each time DFHSM services the volume. DFHSM then implements the required services for the data set to
insure that the data set is migrated after a specified interval and that adequate backup copies of the data set are maintained. If
no management class is specified, then data set level services are not provided by DFHSM. However, the data set is still
considered to be system managed.7

6 The data class routine is only invoked for new data set allocations. If an existing data set is being recalled,
migrated, or converted the data class ACS routine is bypassed.
7 As a safety net to this process, a default management class may be specified in the SMS base configuration.
 SMS ACS ROUTINES

New Allocation Data Storage Mgmt Storage

Class Class Class Group

Null Null Null 1 to 15

or One or One or One Groups
No
SMS Controlled
Null
Allocation
Yes

Non SMS Volumes SMS Volumes

No
VIO
Yes

Real / Estor

Figure 4. ACS Routine Execution

The fourth ACS routine is the storage group routine. The storage group routine selects the candidate storage groups8 on which
the data set may be allocated. Unlike the other three ACS routines, the output of the storage group routine is a list rather than
a single output variable. This list is called &STORGRP and it may contain as many as fifteen storage group names. With the
exception of the storage group that designates VIO, no priority is inferred by the order of the potential storage group names
returned in the list.
The final test shown in Figure 4 is the determination of whether or not the data set is to be allocated on a SMS controlled
volume or serviced by VIO. The selection of VIO is based on the size of the data set for temporary allocation as specified by
the VIO Storage Group Define [5,6] screen under ISMF. While this screen allows SMS to differentiate by data set size, the
demand for the system’s central and expanded memory is considered as a factor during the allocation of a VIO data set.
Observation: as currently implemented, SMS does not communicate with SRM to determine the UIC or the Migration
Age of the system’s storage subsystem prior to the allocation of a VIO data set. While it may be argued that the
condition of the storage subsystem at the time of allocation may not be an ideal indicator about the future behavior
of the system, the inclusion of UIC and Migration Age criteria would allow the user to avoid the types of immediate
performance problems that have led many installations to curtail the use of VIO in the past.
It is hoped that these allocation criteria for VIO data sets will be added to SMS in the future.
In the event that the allocation is not serviced by VIO, the remaining storage groups are then used to identify candidate volumes
for the physical allocation of the data set. When the data set is actually allocated, the &DATACLAS, &MGMTCLAS,
&STORCLAS, and &STORGRP for the data set are recorded in the VVDS data set on the volume selected for allocation and
an entry is created for the data set in the systems BCS as is shown in Figure 5. These values are used to control other data set
services provided by SMS or one of its subsystems. For example, the &MGMTCLAS is used to control the services provided
by DFHSM and the &STORCLAS is used by SMS’s Dynamic Cache Management algorithms to implement data set level
caching.

8 A storage group is a set of volumes defined by the storage administrator to serve the needs of a particular subset
of the system’s data.
 Entries for: [Link]

VTOC
DSN

VTOCIX DSN Extent Pointers

VVDS DSN Pointer to VTOC STORCLAS Open: CASF Token

MGMTCLAS
DATACLAS

DFHSM
Services

Data Set

Figure 5. VTOC, VTOCIX, and VVDS Entires Created by an SMS Controlled Allocation

After initial allocation, the ACS routines are not executed again for the data set unless the data set is moved, recalled, or
restored. This means changing your ACS routines will only influence future allocations, not modify the status or services
previously requested for data sets that have already been allocated.
Observation: to minimize overhead, ACS routines are only executed for a data set at the time of allocation. While
this is ideal in most cases, the reader should note that ACS routines are not redriven when a data set is renamed which
may result in an unexpected data set being found on an SMS controlled volume. Moreover, some data set services
like backup/restore must be used to process existing data sets to allow them to exploit new configuration features like
additional or enhanced cache control units.
4.0 Device Selection
The selection of a device for the allocation of a SMS controlled data set is a complex process. In this section, we will examine
how SMS determines the performance capabilities of the devices it manages, how free space tables are maintained within and
among SMS hosts, how SMS constructs the primary and second lists of candidate volumes for data set allocation, and how
SMS interfaces with the SRM at the time of allocation to select the specific volume on which the data set will actually be
allocated.
4.1 Expected Device Performance
When an SMS configuration is activated, SMS employs DFP module IECDINIT (non-OCO) [7] to build a device performance
capabilities entry for each of the volumes defined by the Storage Groups. In particular, the IECDRDCI (read device
characteristics information) routine issues a RDC CCW to each device to determine the devices extended device type class
information. The data collected by this routine is merged with the control unit characteristics gathered by the OCO module
named IECCINIT. While the specific characteristics of this module are not documented, the author has inferred that the module
determines the control unit type, features, cache size, and a number of other control unit characteristics based on the device
performance capabilities entry that is constructed for each SMS managed volume. The device performance capabilities entry
is a pointer into a non-executable CSECT name IECDPERF.[8] These pointers are shown in the lower left hand corner of
Figure 2.
Module IECDPERF contains the expected device performance entries for a variety of different control unit and device type
combinations. For each combination there are eight half-word entries in the IECDPERF module. These entries provide the
expected values for cached and native (i.e., uncached) direct read, direct write, sequential read, and sequential write operations.
Table 1 provides a table of these entries extracted from the DFP 3.3 version of this module. For example, the last line of the
table indicates that the expected direct and sequential read times for a 3390 disk supported by a 3990-3 control unit with the
fast write feature enabled are 10 milliseconds and the expected direct and sequential write times are 6 milliseconds. With the
cache disabled for the device (i.e., never-cache specified), all of the expected service times are 25 milliseconds.
Observation: as can be seen in the table, SMS has the capability to exploit the characteristics of several generations
of control units and devices. For example, the first entry in the table is for 3350 disk drives supported by 3880-1
control units. This feature should be of particular interest to installations that have several generations of DASD
technology to their current configuration by lease or depreciation schedules.
Thus, SMS’s view of device performance is based on vendor supplied expected values of device performance rather than any
measurements of actual device performance collected by RMF or any other mechanism. The dynamic approach to initialization
based on the RDC CCW will make it a complex problem for third party hardware vendors to apprise SMS of the capabilities
of SSD or EDASD devices. Since these devices typically respond to a RDC CCW by indicating that they are an uncached
single density 3380 volume, SMS will assign them relatively slow expected values for device performance and will tend to
 Direct Direct Seq Read Seq Write Native Native Native Seq Native Seq
Read Write Direct Direct Read Write
Read Write
3880-1/3350 31 31 31 31 31 31 31 31
3880-1/3375 31 31 31 31 31 31 31 31
3880-1 SMB/3375 31 31 31 31 31 31 31 31
3880-3/3380 25 25 25 25 25 25 25 25
3880-3 SMB/3380 25 25 25 25 25 25 25 25
3880-3 3005/3380 25 25 25 25 25 25 25 25
3990-1/3380 25 25 25 25 25 25 25 25
3880-2/3380 25 25 25 25 25 25 25 25
3880-13/3380 14 25 14 25 25 25 25 25
3880-23/3380 10 25 10 25 25 25 25 25
3880-23 3010/3380 10 25 10 25 25 25 25 25
3990-3 NFW/3380 10 25 10 25 25 25 25 25
3880-3 NFW/3390 10 25 10 25 25 25 25 25
3990-3 FW/3380 10 5 10 5 25 25 25 25
3990-3 FW/3390 10 5 10 5 25 25 25 25
Table 1. IECDPERF Expected Device Performance Values, Msec

avoid them for important or high performance data sets unless some way is found to circumvent SMS’ dynamic initialization
process. As will be discussed in the following section, the most practical way for an installation to exploit such devices today
is to define them by vertical storage pools and carefully control the assignment of this pool with their ACS routines.
4.2 Free Space Table Maintenance
A second function performed during the SMS initialization process is the development of a free space table for each SMS
managed volume in the SMS address space. This table is constructed by reading the VTOC index for each volume to determine
the available free space at the time the SMS configuration is activated. This process is shown in the lower right hand side of
Figure 2. Every time SMS allocates new data set or an additional extent for an existing data set on a volume, DADSM updates
the SMS free space table. While this update process maintains a correct free space value for a volume managed by a single
system, allocation by other systems that share the volume cannot be accounted for by this method. To address the multi-system
communication issue, SMS uses a relatively low activity mail box data set called the COMMDS. Every fifteen seconds (or
other value specified by the user using the INTERVAL parameter) each of the systems in the SMS configuration read and
write a variety of critical data elements to the COMMDS. Among these elements are the free space levels for each of the SMS
managed volumes. By interchanging the free space information on a reasonably frequent basis, each system maintains an
approximation of the volumes’ free space without incurring the overhead of processing the volume to determine the available
free space prior to the allocation of a data set.
4.3 Constructing the Primary and Secondary Volume Lists
As was discussed in Section 2, the ACS routines pass the data class, storage class, management class, and a list of potential
storage groups for the allocation of each data set to the SMS data set allocation routines. In the storage class for the data set,
the storage administrator has specified the millisecond response time target (MSR), the read/write bias, and direct/sequential
bias for the data set. That is, the service requirements for the data set. The data class (or the specific allocation values provided
by the user) provides the size of the data set that must be allocated.
Using the expected values of device performance created by IECDINIT and the free space tables maintained in the SMS address
space, two lists are constructed. The first list is the primary volume list. It contains all of the volumes in the candidate storage
groups that meet all of the following requirements:
• storage group that contains the volume is enabled,
• volume status is enable,
• volume is online,
• volume will contain the primary extent without exceeding the high threshold,
 • satisfies the storage class availability attribute,
• meets or exceeds the storage class performance objectives, i.e., MSR.
The secondary volume list contains all of the remaining volumes that are online and satisfy the storage class availability attribute
and meet any of the following criteria:
• storage group or volume status is quiesce or queisce new,
• volume will contain the primary extent,
• does not meet all of the storage class performance objectives.
A special case that should be noted is the storage class attribute called guaranteed space. If quaranteed space is specified, the
volume serial number9 specified in the user’s allocation request will be honored. In that case, the primary list will contain the
specified volume(s) and the secondary list will be null.[14]
As was discussed in Section 2, the ACS routines pass the Data Class, Storage Class, Management Class, and a list of potential
Storage Groups for the allocation of each data set to the SMS data set allocation routines. In the Storage Class for the data set,
the storage administrator has specified the millisecond response time target (MSR), the read/write bias, and direct/sequential
bias for the data set. That is, the service requirements for the data set. The Data Class (or the specific allocation values provided
by the user) provides the size of the data set that must be allocated.
SMS tends to allocate each new data set on the highest performance available device in the primary list.[6,9] The author refers
to this effect as service level escalation. This factor should be considered when the storage administrator designs their storage
groups. There are two approaches that have been suggested for the design of storage groups, they are vertical and horizontal
storage pools. A vertical storage pool defines a set of like devices behind the same or similar control units. A horizontal storage
group can include devices with a variety of different expected response time values provided that all of the devices share a
common track format. Figure 6 depicts alternative vertical and horizontal pool specifications for four strings of DASD. The
horizontal pools are organized by application (i.e., data base, CICS, TSO, and library) while the vertical pools are organized
by the level of expected performance. While the horizontal storage pool concept initially appears to be very attractive for
allowing SMS to assign some key data sets in every Storage Group to high performance devices, SMS will defeat a horizontal
pooling strategy by loading all data sets, regardless of the service levels requested, from the top down (in terms of service)
within the pool.
Observation: based on SMS’ tendency to escalate service levels, the author recommends against the definition of
horizontal pools. The use of horizontal pool definitions will tend to result in the over utilization of high performance
devices and the under utilization of older or slower device technologies.
The reader should note that providing SMS a choice of multiple vertical storage groups (i.e., pools) that have different service
level capabilities in the parameter list returned by the Storage Group ACS routine has the same effect as the definition of
horizontal storage pools. At the time of allocation, SMS looks at all of the volumes in all of the Storage Groups specified by
the ACS routines as a super set pool for the purposes of the data set allocation process.
4.4 Interface with the SRM
After the primary and secondary volume lists have been constructed10, the primary list is passed to the SRM to select a specific
volume for the allocation of the data set as is shown in the top center of Figure 2. The SRM function employed is the same
one that has been used for SYSDA and other non-specific volume allocations for many years. Simply described, the SRM
examines the instantaneous utilization of the LCUs that support the candidate volumes and returns a suggested volume for the
allocation.[10] If the allocation fails, the suggested volume is removed from the list and the SRM selection function is invoked
again. An allocation may fail if another system has allocated a data set on the candidate volume that has not yet been
communicated to the allocating system via the COMMDS. In the event that allocation on all of the primary volumes fail or if
the primary volume list is null, the data set is allocated on secondary volume that contains the greatest quantity of free space.
Observation: device selection based on LCU load also tends to favor (i.e, escalate to) higher performance devices
over older technology. Specifically, the LCU load measured for a DLSE string would be far lower than that for a
comparable DLS string of devices at the same I/O rate.

9 Mulitple volume serial numbers may be specified for multi-volume data sets.
10 While the term list seems to imply that there might be a multitude of potential volumes to choose from, in
some cases either the primary or secondary volume lists may be null based on the number of volumes in the storage
groups and the availability of free space on the candidate volume.
 HighPerf R-Cache MedDen LowDen

Vertical Pools 3990-3 DFW 3880-3 3880-3

3880-23

3380 J/K 3380 J/K 3380 D/E 3380 AA

Horizontal Pools 3990-3 DFW 3880-23 3880-3 3880-3

Data Base

CICS

TSO Data

Library
3380 J/K 3380 J/K 3380 D/E 3380 AA

Figure 6. Vertical and Horizontal Pool Design

When the data set is allocated on a volume, DADSM updates the free space table on the system that allocated the data set.
Then, the SMS address space on the allocating system communicates the revised free space status of the volume to the other
systems that share the volume by updating the COMMDS. In addition, the new data set is cataloged in the system’s basic
catalog structure (BCS) and a VVDS entry for the new data set containing its Data Class, Management Class, and Storage
Class is created for the data set at the time of allocation.

5.0 Dynamic Data Set Caching

The final aspect of the overview of SMS data set allocation and performance management depicted in Figure 2 is dynamic
data set caching. Simply described, SMS manages the 3990-3 cache to insure the performance of must-cache data sets and
improve the performance of may-cache based on the utilization of the 3990-3’s cache and non-volatile storage (NVS). Rather
than volume level approach to cache management that was employed on the 3880-13 and 3880-23, SMS allows the cache’s
resources to be directed at the data set level.

5.1 Must, May, and Never-Cache Data Sets

As was discussed in Section 3, the storage class returned by the ACS routines specify the target millisecond response time
(MSR) for the data set. In addition, the storage class may also indicate whether the data set is read or write and/or sequential
or direct biased. At allocation time, these attributes are used to select a candidate volume that meets or exceeds the service
level target for the data set.

When a storage class is created, the storage administrator specifies a MSR target between 1 and 999 milliseconds. At DFP 3.3
level, the granularity of this specification is somewhat less than is implied by the range of available values. Specifically, the
numeric range is mapped to three categories. They are:

Never-Cache: a MSR of 999 milliseconds is specified by the storage class,

May-Cache: a MSR of less than 999 milliseconds and greater than or equal to 25 milliseconds is specified
by the storage class,
Must-Cache: a MSR of less than 25 milliseconds is specified by data set’s storage class. In addition, the
specification of a write bias for the storage class restricts the primary volume list to devices
supported by 3990-3’s with the DASD fast write (DFW) feature enabled. To improve
overall performance, the VTOC, VTOCIX, and VVDS data sets on each SMS managed
volume are also treated as must cache data sets when the volume is supported by a 3990-3
with DFW.
Table 2 provides the expected millisecond response time ranges of 3880-13, 3880-23, and 3990-3 cache controllers for variety
of read/write and direct/sequential biases. The reader should note that the specification of any write bias characteristic insures
that only volumes supported by 3990-3 will be selected for the primary volume list at the time of allocation. In addition, at the
DFP 3.3 level, there is no ability to specify the priority of cache utilization by may-cache through the value (i.e., 25 to 998)
specified for the MSR.
Observation: despite the current lack of any support of cache priority for may-cache data sets, the author recommends
that users employ a wide range of MSR targets for may-cache to position the SMS implementation for future releases
of DFP that may offer cache priority.

Read Bias Read Bias None Write Bias Write Bias

Seq Direct Specified Seq Direct
3880-13 14<=MSR<25 14<=MSR<25 14<=MSR<25 N/A N/A
3880-23 10<=MSR<25 10<=MSR<25 10<=MSR<25 N/A N/A
3990-3 DFW 10<=MSR<25 10<=MSR<25 10<=MSR<25 6<=MSR<25 6<=MSR<25
Table 2. Must Cache Data Sets

At the time a data set is opened, the caching requirements of the data set are determined and are used to create a CASF token.[8]
The CASF token is created based on the &STORCLAS value recorded for the data set in the VVDS when it was initially
allocated. The token will be used during subsequent I/O operations to communicate the specific service requirements of the
data set to the IECDSCAN routine. This routine dynamically modifies the define extent CCW (i.e., turns on the cache inhibit
bit) for each I/O for individual data sets to implement data set level caching.
5.2 3990-3 Communication
SMS interrogates the 3990-3 control unit every 150 seconds, or at an interval specified by the DINTERVAL parameter in
parmlib. The process, call read cache statistics, extracts a control block [11] from the 3990-3 similar to the one processed by
the RMF Cache Reporter to analyze 3880-13 and 3880-23 performance. The read statistics task calculates:
• the number of system managed devices behind the cache,
• percent may-cache reads allowed to use the cache,
• percent may-cache writes allowed to use NVS,
• percent cache read hits,
• DASD fast write waits per minute.[12]
These data elements are saved in a table for subsequent use by the IECDSCAN routine which modifies the data set level CCWs.
Based on the load being experienced by the cache, the IECDSCAN routine can apply the cache’s resources to improve the
performance of may-cache data sets.
5.3 Dynamic Caching
Figure 7 provides an overview of SMS dynamic caching. As is shown in the figure, a CASF token is created at open time based
on the storage class stored in the VVDS entry for the data set that is used to communicate data set service requirements to the
dynamic caching routine. In the event that the read cache statistics task discussed in the prior section determines that the cache
and/or NVS is over loaded, then read and/or write I/Os for may-cache data sets are momentarily denied access to the cache’s
resources. The reader may wish to note that IECDSCAN manages the access to 3990-3’s traditional cache for reads and NVS
(i.e., DFW) for writes independently. Relatively few details are available concerning the specific algorithms that implement
dynamic cache management. However, a number of PTF and APAR entries [13] have provided some insight in general control
philosophy employed. Access for may-cache reads is based on the percent of may-cache reads allowed to use the cache statistics
that is returned by the read cache statistics task. Based on a discussion in an APAR entry, this algorithm inhibits access to the
cache for may-cache reads when the percentage returned by the read statistics task exceeds 70%. Access for may-cache writes
is based on the number of DASD fast write waits per minute. As long as this statistic is less than 60 fast write waits per minute,
may-cache writes are allowed to use NVS.
 Observation: while the specific characteristics of the dynamic cache management algorithms are not known, the
default sampling interval of 150 seconds is long when compared to the expected duration (i.e., data set open to close
time) of many of the processes like TSO CLISTs or short batch jobs that MVS manages. As such, dynamic caching
will often be basing its decisions based on the prior behavior of the 3990 rather than the specific access characteristics
of many of the active data sets.

ACS Routines Start I/O

DC MC
IECDSCAN
SC SG Evaluate data set
SC ==> MSR level I/O requests
relative to CASF
token and cache
status
OPEN Process Must
May Modify CCW
Evaluate storage
Never
class and define Execute the I/O
CASF token

Dynamic Cache Management

Interrogate 3990-s
3990-3
at DINTERVAL

N
Calculate cache DCF Cache Statistics
and NVS load Default DINTERVAL=150 Secs
V
indicators S

Figure 7. Dynamic Cache Management

Even for long running processes, the statistics passed by the 3990-3 describe the performance of the cache at a high level rather
than the access characteristics of the individual data sets that are using the cache. Therefore, dynamic cache management can
sense that there is a problem in the cache, but cannot determine the specific data set which is causing the problem. Hence,
dynamic cache management will tend to reduce the use of the cache resource by all may-cache data sets since it is unable to
identify the specific data set(s) that are overloading the control unit.
Observation: it is imperative that data set level analysis tools be used to verify that must-cache data sets have desirable
cache characteristics. That is, data sets that have good locality of reference as well as an acceptable write percentage
depending on the types of control units that are available.
Furthermore, it is recommended that must-cache data sets be identified on a data set by data set basis using the data set profile
segment of RACF [3] rather than attempting to use a wild card or data set name pattern in the storage class ACS routine while
3990-3 DFW control units remain a precious resource in most installations.
One interesting operational aspect of Dynamic Data Set Caching that should be addressed by future research is the management
of shared 3990-3 controllers. Since multiple copies of SMS executing on different hosts act independently (i.e., there is no
master/slave relationship between the systems), it is not clear how the dynamic caching routines on one host will react to
problem data sets introduced by another host that shares the system.
Observation: the operation of the multiple independent copies of the dynamic caching routines in a shared DASD
environment presents a variety of interesting questions. These questions should be investigated by benchmark studies
in the future.
Without the benefit of experimental data, it appears to the author that shared DASD performance could be significantly impacted
by the presence or one or more erroneously classified may-cache or must-cache data sets on any of the systems that share a
control unit.
6.0 Remarks
SMS is a complex tool that can greatly simplify the role of the performance analyst in the proper placement and maintenance
of data set service level requirements. While not a panacea, SMS has the capability to employ a wide range of control unit
and device characteristics to meet the service level requirements of data sets. However, insuring the performance of critical
data sets remains the responsibility of the performance analyst since the current implementation of SMS provide no facilities
to guarantee the performance of individual data sets.
References
[1] Data Facility Data Set Services: Reference, SC26-4839, IBM
[2] Data Facility Hierarchical Storage Manager: Version 2 Release 4.0 General Information Manual, GH35-0092, IBM.
[3] Resource Access Facility (RACF) General Information Manual, SC28-0722, IBM.
[4] DFSORT General Information Manual, GC33-4033, IBM.
[5] DFDSS Implementation Student Materials, J3611SH-1, Fig 3-40, IBM.
[6] MVS/DFP Version 3 Release 2: Storage Administration Reference, SC26-4566.
[7] IECDINIT, Microfiche LJB6-0193, LJB6-0198, and LJB6-0196, IBM.
[8] IECDPERF, Microfiche LJB6-0196, IBM.
[9] DFSMS Implementation Student Materials, J3611SH-1, Fig 8-36/37 IBM.
[10] MVS/ESA System Programming Library: Initialization and Tuning, GC28-1828, IBM.
[11] CSECT IGDCAT, [Link] Level 3.1.0, IBM.
[12] Delliquadri, Ho, and Ritter, DFSMS Annoucement/Update Workshop, September 1989, IBM.
[13] PUT 8906, APAR OY22664, PTFs UY39815 and UY39816, IBM.
[14] Camacho, A., SY-7656: DFSMS - Volume Selection Overview, Guide 77, 1990.