Thanks very much to all those who responded to my post. You have all answered my questions and cleared some nagging doubts.
________________________________ From: Joel C. Ewing <[email protected]> To: [email protected] Sent: Monday, January 21, 2013 9:46:30 AM Subject: Re: VTOC QUESTION On 01/21/2013 07:59 AM, esmie moo wrote: > Good Morning Gentle Readers, > What are the advantages of having a large VTOC defined when initializing a >volume besides having a large amount of Free DSCBS? Would a smaller VTOC >cause response time problems? > For example I am adding 3390-9 volumes (10,017 cyls per volume) to a STORAGE >GROUP which will only alloc certain dsns which are equal or larger than 1,500 >cylinders. > From my rough estimation not more than 650 dsns would fit on that volume. >Could a vtoc of 29 trks suffice? > Thanks for your welcoming comments in advance. > > 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. 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. -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
