The minimum portion of space, that can be allocated to a tablespace is ONE track ( = 48 kB available space ). So each value for PRIQTY and SECQTY is rounded up to the next multiple of 48 ( or 720, if CYLs are used to allocate the tablespace ).
If tablespace is segmented, the secondary extent-size might also be adjusted, so that a complete segment can be stored.
There are also ZPARM-parameter, which may override your specified values.
( e.g. MGEXTSZ=YES ).
To see, what DB2 really allocated, do a LISTCAT on the vsam-cluster.
By the way: Your select statement states, that there are 47 extents, but you received an abend due to 251 extents ? Seems, that one value is not up to date
I ran this query after Changing the tablespace(Reorg and Runstats).
Even though the primary and secondary are rounded up for the tracks , it will be max 10000 KB (3020 KB) . But the space column shows 198528KB which is 138 average record length * 1410420 no of records approximately.
My doubt is how the less number of primary quantity and secondary quantity could hold this number of bytes. Is Db2 taking the space allocation from something else. I have referred "Estimating disk storage for user data". Please guide me in understanding the concept behind the space column.
The VSAM dataset shows in tracks and fileaid has the following.