Your formula can be off by a significant amount. 56664 is the track capacity of a 3390 disk drive -- but 55996 is the most that can be used (27998 times 2), and the actual used bytes per track can be much different. For example, if a load library has BLKSIZE of 23200 (which I've seen for vendor software), that is 46400 bytes per track used -- so your dividing by 56664 will be low by about 20%. Multiply UMALLSP by 1024 and then divide by UMBKLNG to get the actual number of blocks used -- then you have to consider the number of blocks per track in calculating tracks to get the two estimates close together.

Vasanth, I suspect that this is where your problem lies. From the little research I've been able to accomplish, it appears that the DCOLLECT M record allocated space value includes both the data and index components for a KSDS. And it appears that the space allocation figure is based upon the larger CA size between the data and index components -- the other is converted into the larger units.

So a KSDS file allocated with data component of 5 cylinders and 3 tracks for the index component will have M type record space allocation of 75 tracks for data and 15 (1 cylinder since the data component is using cylinder CA size) tracks for the index, or a total of 90 tracks allocated space (4316 k-bytes in the M record). The actual space used would be 78 tracks (3834 k-bytes) if restored.

This tells me you cannot rely upon the allocated space in the type M DCOLLECT records for VSAM files. The actual space required for the restored data set may be more -- or less -- than the calculated value based on the M record allocated k-bytes.