z/OS DFSMSdfp Storage Administration
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Honoring specific volume requests

z/OS DFSMSdfp Storage Administration
SC23-6860-01

If you specify Guaranteed Space=N, SMS chooses volumes for allocation, ignoring any VOL=SER JCL statements. Primary space on the first volume is preallocated. NO is the default.

Specifying volume serials with the Guaranteed Space attribute of the storage class is strongly discouraged. If used, the following considerations must apply:
  • Ensure that the user is authorized to the storage class with the Guaranteed Space attribute.
  • Write a storage group ACS routine that assigns a storage group containing the volumes explicitly specified by the user.
  • Ensure that all volumes specified by the user belong to the same storage group by directing an allocation with a Guaranteed Space attribute to all the storage groups in the installation.
  • Ensure that the requested space is available on the volume because there is no capability in SMS to allow specific volume requests except with the Guaranteed Space attribute.
  • Ensure that the availability and accessibility specifications in the storage class can be met by the specified volumes.

With the IBM® Enterprise Storage Server® (ESS), the guaranteed space attribute of a storage class with specific volume serials is no longer required for data sets other than those that need to be separated (for example, DB2® online logs and BSDS) or that must reside on specific volumes because of their naming conventions (for example, VSAM RLS control data sets). The ESS storage controllers use the RAID architecture that enables multiple logical volumes to be mapped on a single physical RAID group. If required, you can still separate data sets on a physical controller boundary for the purpose of availability.

The ESS capabilities of multiple allegiance and parallel access volumes (PAV), along with its bandwidth and caching algorithms, make it unnecessary to separate data sets for the purpose of performance. Traditionally, IBM storage subsystems allow only one channel program to be active on a disk volume at a time. This means that once the subsystem accepts an I/O request for a particular unit address, this unit address appears “busy” to subsequent I/O requests. This ensures that additional requesting channel programs cannot alter data that is already being accessed. By contrast, the ESS is capable of multiple allegiance, or concurrent execution of multiple requests from multiple hosts. That is, the ESS can queue and concurrently execute multiple requests for the same unit address from multiple hosts, provided that no extent conflict occurs.

The ESS can also execute multiple concurrent accesses to a single volume from a single host or PAV. To access a volume concurrently, you must associate multiple device numbers with a single volume. The ESS provides this capability by allowing you to define a PAV-base address and one or more PAV-alias addresses. It allows up to 255 aliases per logical volume. Therefore, you no longer have to separate data sets from each other for performance reasons.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014