28 128 pages 32
≥ 128 pages 64

i don't think you will suffer greatly by creating all your tablespace with segsize 64

The greater number of pages in each segment (AKA, the higher the SEGSIZE value), the fewer pieces of control information are kept in your tablespace.

Todd

ednic, I generally use a SEGSIZE of 4 for tiny table spaces (tables with 1-10 pages such as code tables) and a SEGSIZE of 64 for all other table spaces (that are not partitioned).

Part of the reason is that a large SEGSIZE will waste space. If you have a table that will only use 1 page to hold all the data (there are a couple of other control pages also) with a SEZGIZE of 64, 64 pages will be allocated even though you will only ever use 1-3 pages. That works out to 6 tracks (of 3390 disks). While that might not sound like much, that extra 5 tracks times enough table spaces does add up.

NOTE: You can test this out by creating a Table space with a SEGSIZE of 64 and a PRIQTY and SECQTY of 48 (1 track). After it is created, go look at the VSAM file created and see what size it is.

SEGSIZE also affects Prefecthing. This is why I generally just jump straight to a SEGSIZE of 64 for most all data tables. It will allow the most pages to be prefetched for you asynchronously.

Thanks for the info.

feel free to use 64 on all. Just remembering that V9 brings the universal tablespace where you can exploit SEGSIZE and patitioned feaures in the same tablespace

Regards