The total of records is 400000. as i already know the calculation, i have calculated using 27998/611=46 rec/block. no.of.rec/46 = 8696 blocks. so i have allocated more SPACE=(10796,(10000,100),RLSE) for a safer side and resolved the issue. But my question is what is the role block length (10796) playing here? whether i need to bother abt 10796?
Thats True Dick. But my question is whether 10796 will be having any effect on space calculation? whether i need to consider that as an parameter while calculating space? As i mentioned BLKSIZE = 0, it will take the optimum block size, But just want to clarify and to be clear.
Your calculation is based on half-track blocking (27998 bytes maximum per block). Your selected block size gives 17 records per block. 400,000 records divided by 17 gives 23,530 blocks required -- not the mere 10,000 you allocated.
Also, 10796 is not evenly divided by 611. You should be using 10387 instead (or 10998?) to be evenly divisible.
I suspect this is an SMS-managed data set and the BLKSIZE=0 is overriding your specified block size. If this data set were going to a non-SMS volume, you would be getting an abend stating that block size is not a multiple of LRECL.
In order to prevent future confusion, change the 10796 to TRK or CYL and adjust the allocation number appropriately.
