Isn't it a bit odd that allocation of DB2 tablespaces and DB2 indexes must be made in kilobytes (KB). Everything in DB2 are stored in pages and each page has a size of 4KB. I am always thinking in pages when I think of the size of a DB2 space, and I bet you do as well. As far as I remember IBM formulas for calculating space sizes are giving results in number of pages. To confuse us all pages are stored in VSAM datasets which are allocated in tracks or cylinders. This is all quite a mess.

I hope this tip will clear up this mess for you with some easy rules of thumb. If you want to allocate your VSAM datasets in tracks it is convenient to express PRIQTY and SECQTY in multiples of 48KB, for instance PRIQTY 480 SECQTY 240 which will result in a primary allocation of 10 tracks and a secondary allocation of 5 tracks. If you want allocation in cylinders then use multiples of 720KB, for instance PRIQTY 14400 SECQTY 2880 giving 20 cylinders primary and 4 cylinders secondary. If you don't use multiples of 720KB, you might risk that DB2 allocates in tracks. All the allocations are for 3390 disk types. Many years ago when 3380 disk types were still around the multiples were 40KB and 600KB.

Now you are able to calculate how many pages there are on a track. This is interesting, because you cannot allocate less space than a track. On 3390 disk types you can have 12 pages and on 3380 you had only 10 pages. Old MVS people like me can see that this is a complete waste of space leaving 6844 bytes of unused space for every track. This is more than a whole DB2 page. Well, IBM is selling disks as well as computers, aren't they. I hope modern RAID systems can ignore this kind of waste.