The dataset has to be redefined to change the SPACE allocation. At this time it gives the opportunity to also change the Dataclas which can enable things like Compression, Extended Format & Addressibility, Space Constraint Relief and Extent Constraint Relief, all of which could be beneficial.
Getting the FREESPACE right is not always easy. First you need to decide if you need it. Generally it's only necessary if large numbers of inserts are being made in a short period. Once CI/CA split overheads have occurred then the freespace is inserted into the areas it's needed so splits are not always a bad thing.
It's important to make sure your CISIZE is a good fit for the record size(s). For example if your RECSZ is 398 then a CISIZE(4096) is reasonable fit as only a few bites are left unused within the CI after 10 records are inserted. But, CISIZE also has an effect on DASD usage, so ones nearer a half track size are more efficient for DASD usage. But the application usage of the dataset does come into play as well. The bigger the CISIZE the larger the amount of data is being transferred in an I/O operation. Depending on performance requirements that can require a balance between DASD usage and performance with a compromise on CISIZE.
The FREESPACE percentage needs to equate to one or more of the RECSZ. For CISIZE 4096 a 10% CI freespace figure would be ~ 409 bytes which would fit a 398 byte record quite comfortably. CA freespace is sometimes difficult to gauge until the dataset is loaded or in use for a while and the number of CA splits becomes evident.
One thing to note about FREESPACE specified on a DEFINE Cluster is that it is included in the initial allocation of space taken by the dataset, so can significantly increase the size.
In any case be guided by the IBM manuals called 'VSAM Demystified' or 'Using Data Sets' which will be much more accurate than what I have put here.