Page 1 of 1

User catalog extents

PostPosted: Wed Oct 13, 2010 3:23 pm
by Srini Srini
Hello,

Could some one tell me what will be the implications if a usercatalog extends over multiple extents? Why all the user catalogs are monitored to have a single extent?

Thank you..

Re: User catalog extents

PostPosted: Wed Oct 13, 2010 4:23 pm
by Robert Sample
Performance could be impacted since the data may not be contiguous.

However, you have an incorrect assumption in your post. The DFSMS AMS for Catalogs manual in section 19.1.1 on DEFINE USERCATALOG specifically states
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.
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.

Re: User catalog extents

PostPosted: Wed Oct 13, 2010 4:43 pm
by Srini Srini
Thanks Robert,

Can the Usercatalog extend onto multiple volumes if the secondary space is allocated to it?

Thank you.

Re: User catalog extents

PostPosted: Wed Oct 13, 2010 5:11 pm
by Robert Sample
The DFSMS AMS for Catalogs manual implies user catalogs can use multiple volumes:
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.
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.

Re: User catalog extents

PostPosted: Wed Oct 13, 2010 9:31 pm
by Bill Dennis
With modern virtual arrays, nothing is contiguous anymore. We usually reorg a catalog when it gets to 4 or 5 extents just because it makes us feel better.

Re: User catalog extents

PostPosted: Thu Oct 14, 2010 4:05 am
by enrico-sorichetti
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

Re: User catalog extents

PostPosted: Thu Oct 14, 2010 7:49 am
by steve-myers
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
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 ...