Back in week 16/2004 I wrote a tip about SMS compression. I have found out the hard way that this tip was very general. I think there is a need to drill down in the mysterious ways that SMS compression for datasets work before I loose too many of you, my dear readers.

I have discovered that SMS only considers using SMS compression when the primary allocation has a certain size. What the precise size is I have not been able to find out, but about 200 tracks is sufficient. 100 tracks may not be enough.

I usually allocate datasets with a small primary allocation and a large secondary allocation combined with the RLSE parameter like SPACE=(TRK,(15,600),RLSE). Therefore I was very surprised to see a dataset of app. 6000 tracks where the field called SMS comression in ISPF 3.2 was set to NO despite the fact that I used the correct data class. Especially when I considered that the dataset contained unloaded data from a DB2 table with compressed data savings of 88% of space and filling up a lot less than 6000 tracks. Now I use SPACE=(TRK,(600,600),RLSE) if I want to use SMS comression. Before considering using 600 tracks as primary allocation I make sure that the dataset will use more than 600 tracks otherwise I will not use SMS compression at all.

If you are wondering what will happen if you transmit an SMS compressed dataset to another installation, I have tried that as well. All the standard methods I know of will unpack every single record in the SMS compressed dataset to their usual format. This means that you will transmit the full amount of data and not the compressed. I also tried to make an ADRDSSU DUMP DATASET and this utility also unpacks the dataset. I feel certain that HSM also unpacks the dataset and then uses its own compression algorithm to pack it again, but it is hard to prove this theory. I have not tried to create a compressed dataset directly to TAPE. If any of you have experience in this area, I would like to hear from you.