Concepts and Facilities › Special Considerations › Changing the Key of a Compressed VSAM Data Set

Changing the Key of a Compressed VSAM Data Set

To avoid unpredictable results, never compress keys. If you increase the key length or change the RKP, or if you add an alternate key that includes any compressible area in the record, you must expand the data set, delete it from CA Compress using the Control File Maintenance Utility (CFMU), and reimplement it with the new values.

If you reduce the key length or make other changes to the key structure in which all keys still refer only to noncompressible area, reimplementing is not needed. However, if your change significantly reduces the area that must be noncompressible, for example, if you delete an alternate key that is well beyond the beginning of the record, you can get better compression by reimplementing the data set. In some cases, you can eliminate FDT compression in favor of Super Express, a Standard Table, or Hardware Compression, resulting in better performance, especially under CICS.

Reimplement a Data Set

To accommodate a key change, you can reimplement a data set.

To reimplement a data set

1. Expand the data set to an uncompressed backup. An IDCAMS REPRO or SORT OPTION COPY to an uncompressed tape is usually best for a large data set.
2. Delete the data set, then use the CFMU to delete it from CA Compress. If you first delete a VSAM data set from CA Compress, Safeguards processing will no longer be performed, and you will then need to use IDCAMS ALTER RVOL to remove the @ZSAM@ candidate volume from the data component before you can delete the data set.
3. Reimplement the data set, using the IUI or the CFMU, as you prefer. If you are using your own FDT, you should normally create a new one with a new name. If you reuse the same FDT name, any other data set using that FDT, or compressed backups of the present data set made using the old FDT, will be unreadable using the new FDT.

If you are using your own FDT, now is the time to consider whether you should go to a noncustom algorithm, whether Super Express, a Standard Table, or Hardware Compression. If compression is comparable, these offer several significant advantages. Especially under CICS, they give better performance as the system gets busier. The noncustom algorithms require much less region, and they eliminate the danger of user error in the RDL. They also reduce or eliminate performance degradation over time caused by changes to the data since the data were analyzed, because the more specific the RDL is to the data, the worse the RDL performs as the data changes.