A CI Split may cause 5 I/O Operations. So increase the FREESPACE for each records.
Freespace is specified to avoid CI & CA splits, of which more later. A reasonably common specification is FREESPACE (20 25), which basically means that after initial load, 33% of the file is empty. One of the features of STK's Iceberg, is that you get FREESPACE for 'free', as the empty space is not actually stored. This implies that we can specify large freespace values, and so avoid those CI/CA splits. However, life is not that simple. If large values of freespace are specified, then the index levels can increase, and fewer actual records are retrieved in an I-O operation. Both of these impact random performance, and the second one will impact sequential performance. The bottom line is that you need to analyse the insert activity to your file to determine which freespace parameters are best, A reasonable rule of thumb is ;
few inserts, or most inserts at end of file FREESPACE(0 0)
inserts clustered at points in the file FREESPACE(0 50)
data inserted at random, all over the file FREESPACE(20 25)
The CI size is the 'blocksize' for a VSAM file. A small CI size will impact sequential processing, a large CI size can adversely impact random processing. A small CI size will also use more disk space. A reasonable rule of thumb is to use a 4K CI for small files, and 8K for large files, with performance assisted by buffering when necessary.
You cannot specify a CA size directly, but a big CA size will reduce the frequency of CA splits, and reduce the number of index levels. The downside of course, is when you do a CA split, you move more data. If a VSAM file is allocated in cylinders, the CA size will be one cylinder. Otherwise, it is the smaller of the primary and the secondary allocation unit.
Priya, talks sense.
BUT - allocating the freespace as he does can cause waste of space.
The freespace for the CI has to be calculated depending on the record length. If the freespace is too big, for instance works out to 48 bytes of your CI, but your record is 25 long, then you always waste at least 23 bytes.
If the freespace is too small then you cannot insert a record, you just waste space.
It is a long time since I did this(about 20 years) , so I do not remember how long a CI is, so I cannot give you more explicit advice. I think it is 4096 from which you have to remove about 4 or 8 bytes, which are used to hold the record length etc. Then you do you freespace calculation.
Basically each VSAM dataset has to be considered individually.
If you get this right it can save huge amounts of access time, and most VSAM datasets will keep themselves tidy.
I did this plus a few other things at a site in 1987, they ended up cancelling an order for a new CPU.
Unfortunately most companies are not willing to listen to this type of advice.
