On Jan 21, 2013, at 8:46 AM, Joel C. Ewing <[email protected]> wrote: > I have never seen any indication that having excessive free DSCBs has any > impact positive or negative on new data set allocation, and if you have a > VTOC Index defined (which should always be the case) there should be minimal > correlation between VTOC size or used DSCBs, and response time when accessing > the VTOC. On the other hand, having no DSCBs left and having unusable free > space left on the volume that you would like to use is a serious > inconvenience. Throwing extra cylinders at the VTOC at initialization has a > minimal cost in DASD space and can avoid future grief. Having to > micro-manage VTOC sizes and/or location is not a profitable use of time.
The only downside of a too large VTOC is that the extra space is not available for data sets. Since I've set up the SMS pools by size, I can adjust the VTOC size to match each pool. I have an initialization job for each pool. It's not a lot more difficult than "one size fits all." > > I always tried to come up with a "worst-case" VTOC size requirement for each > DASD size and have a single initialization job that could be used in all > cases. It makes life so much simpler and you don't have to worry about > things later if you decide to use the same volume for smaller data sets, or > users circumvent your well-planned SMS strategies by allocating many "large" > datasets with RLSE that end up small. I have a daily job that finds these data sets and uses FDRDSF to move them to the appropriate pool. -- Curtis Pew ([email protected]) ITS Systems Core The University of Texas at Austin ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
