-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Ted MacNEIL Sent: Monday, January 21, 2013 11:45 AM To: [email protected] Subject: Re: VTOC QUESTION >>The only downside of a too large VTOC is that the extra space is not >>available for data sets. >How much space is 'lost' to make a difference? Especially, on a -9 or larger?
The answer is either "42" or else "it depends." If you want to make your VTOC large enough for the worst possible case, then you need to do some research on your own data center and then do some calculations. E.g., if your data center has software in place (SMS exits, e.g.) to limit allocation of new data sets on volser XXX to files of at least YYY megabytes, then you can calculate approximately how many files of that size will fit on volser XXX based on the known size (known to you) of that volume. Let's say the answer is 999. Next you have to calculate how big the VTOC will have to be to hold at least 999 Format 1 and/or Format 8 DSCBs. A 3390 track can hold 50 DSCBS, either exactly or approximately, so that means the VTOC must have 999 divided by 50 tracks, or 20 tracks. You should certainly allow some extra space in the VTOC, so you might want to round those 20 tracks up to 2 whole cylinders. But Format 1/8 DSCBs are not the only kind of DSCBs that might need to be stored in your VTOC. As files grow, some Format 3 and/or 9 DSCBs may be needed. As another poster said, sometimes a user allocates a new file with SPACE=(huge,RLSE). This file might be allocated on XXX but when it is fully created the RLSE function reduces it down to only one track. Even a final size of zero tracks is theoretically possible. If this happens a lot, then many of your 999 DSCBs will be used to hold a Format 1/8 DSCB for a data set that is <<< YYY megabytes. Then someday a user will not be able to allocate a new file of size YYY megabytes because there are no Format 0 DSCBs left in XXX's VTOC but yet there are a gazillion available cylinders of space on XXX. If your data center has some automated process to look for datasets on XXX that are smaller than YYY megabytes and move them elsewhere, then whether or not your users may suffer a new allocation failure will depend on how often your users do a (huge,RLSE) and how often your automated removal process occurs. To be absolutely safe, the worst of all possible worst cases is that every track on a DASD volume could theoretically become a single-track data set. So compute how many tracks are on your volser XXX, then divide that number by 50 and you will know how many tracks in size your VTOC must be. E.g., if you have a 3390-9 with 9*1113 cylinders, then you have 150,255 tracks on the volume. One out of every 50 tracks will be required for the VTOC, so you really have 150,255 times 49/50, or 147,250 tracks available to hold one-track data sets and that VTOC will have to have 147,250 DSCBs divided by 50 DSCBs per track in it, which is 2,945 tracks or 196 cylinders. In other words, only 98% of your huge volume is available to hold user data, and the other 2% must be devoted to holding metadata for the utmost extremely worst case. At the other extreme, the best of all possible best cases is that your mod 9 holds only one truly huge data set. You can then have a one-track VTOC and a one-track VTOC index data set (but with only one data set on the volume, why do you really need a VTOC index there?), plus one more track for the volume label, so three tracks total would hold all the necessary metadata, leaving 150,255 minus 3 equals 150,252 tracks to hold your single humongous file of about 8.4 gigabytes (if you manage to cram 56K bytes on each track, which is possible but not easy to do). It's much more likely that you can only cram at most 52K bytes on each track. Bottom line --> a mod 9 VTOC needs to be somewhere between 1 track and 196 cylinders. It depends. Or 42, which is another good answer based on other criteria. >But is it truly worth the effort? It depends. Whenever a new file allocation fails, some DASD space guru will need to be involved in determining why the failure occurred and what to do to get the file allocated somewhere. That guru may be the original user or may be you. But somebody has to do it, and probably most users don't have the foggiest. How often do your users have a new allocation fail for the reason that the VTOC is too small? Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: [email protected] * w: www.rocketsoftware.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
