Page 1 of 1

Bytes vs Tracks, Blocks, Cylinders, etc.

PostPosted: Tue Oct 27, 2009 6:08 pm
by jbarker36
Is there some simple formula that a person can use to know how many blocks, or tracks, or cylinders one should allocate when creating a dataset when I know how many bytes, kilobytes, gigabytes, etc. a file on my PC is that I will be uploading to my mainframe? If someone could allocate a file in Blocks or Tracks when would I want to choose one or the other. I don't know when someone wants to use one or the other. Due to lack of knowledge I seemed to always allocate way to much space and it would be nice to just have a basic formula or some little Java program that I could plug the amount of bytes I have to know how many tracks, or blocks I would need to allocate to hold it.

Thank you in advance for your help,

-Joleen

Re: Bytes vs Tracks, Blocks, Cylinders, etc.

PostPosted: Tue Oct 27, 2009 8:40 pm
by expat
One track of 3390 DASD is divided into two half track blocks, each having a blocksize of 27798.

If you take the integer valus of divide 27998 by the LRECL - you get the number of records that can be stored on one half of one track. So doubling that gives you the number of records that will fit onto one track.

Knowing that there are 15 tracks per cylinder on DASD, multiply the number of records per track by 15 to give you the number of records that can be stored on one cylinder.

Given these factors, divide the expected number of records by the cylinder or track value to see how much space you require. I usually add 10% contingency and always use the RLSE parameter.

This method is not so accurate for VB datasets as the only LRECL we have to work with is the maximum LRECL, which may result in overallocation of the space, so once again use the RLSE parameter.

Re: Bytes vs Tracks, Blocks, Cylinders, etc.

PostPosted: Wed Oct 28, 2009 12:35 am
by Bill Dennis
Using BLKS was an advantage over TRKS/CYLS back when DASD geometry was changing every few years (3330, 3350, 3380, 3390) and the bytes per track was different on each device. It saved changing the JCL on each migration.

Now, the virtual 3390 is the standard device so track and cylinder sizes should be stable. New development in DASD merely creates virtual devices with evermore CYLS but still as 3390 TRK sizes.

Also, the 3390 track is not really divided into two blocks, it's just usually the most efficient use of space to write BLKSIZEs of half-track size. You can write larger blocks but be aware of wasted space on the track.