So your site may be monitoring the user catalogs to ensure they stay in one extent, but that is site-specific and not a system requirement for z/OS.primary[ secondary]
Specifies the size of the primary and secondary extents to be allocated. After the primary extent is filled, the space can expand to include a maximum of 122 additional secondary extents if you have specified a secondary allocation amount. Secondary allocation should be specified in case the catalog has to be extended. If you specify a secondary space allocation greater than 4.0 gigabytes, the value is reset to the maximum value for that DASD device.
I would be leery of doing that, however, since you'd have to have a LOT of data in that user catalog to need a second volume.VOLUME(volser)
Specifies the volume that is to contain the catalog. VOLUME must be specified as a parameter of USERCATALOG, unless:
* You specify the MODEL parameter, or
* The data set is managed by SMS.
If the data set is SMS-managed, you should not request specific volume serial numbers with the VOLUME parameter. The ACS routines will assign the data set to a storage class containing attributes such as VOLUME and UNIT. You can allocate your data set to a specific volume serial number only if your storage administrator has selected GUARANTEED SPACE=YES in the storage class assigned to the data set. Only then can you specify volume serial numbers that will override the volume serial numbers used by SMS. However, if space is not available on the volumes with the serial numbers you specified, your request will be unsuccessful. See z/OS DFSMS Storage Administration Reference for information about SMS volume selection.
You can choose to let SMS assign specific volume serial numbers to an SMS-managed data set by coding an * for each volume serial. SMS then determines the volume serial. If you omit volser, you get one volume.
If you designate both user-specified and SMS-specified volume serial numbers for an SMS-managed data set, the user-specified volume serials numbers (volsers) must be requested first in the command syntax. Catalogs can only reside on one volume.
The VOLUME parameter interacts with other DEFINE CATALOG parameters. Ensure that the volume you specify for the catalog is consistent with the catalog's other attributes:
* CYLINDERS, RECORDS, TRACKS: The volume contains enough unallocated space to satisfy the catalog's primary space requirement. Space on the volume might already be allocated to non-VSAM data sets and system data sets.
* FILE: The volume information supplied with the DD statement is consistent with the information specified for the catalog and its components.
With modern virtual arrays, nothing is contiguous anymore.
True, though this processing cost is relatively minor, as enrico-sorichetti indicates. The fact that a data set is in a lot of extents rarely impacts applications since all of the code to handle multiple extents is pretty much under the covers. At one time seek costs to move between extents was important, but with virtual arrays this can't really be measured any more, so ...enrico-sorichetti wrote:With modern virtual arrays, nothing is contiguous anymore.
that is certainly true from a strict hardware point of view (seek and friends ),
but mvs/ZOS still does all its elucubrations in terms of 3390 disk architecture
so has to do the processing to walk thru multiple 3390 extents,
not much work but still has to be done