Jeg vil starte med at ønske alle mine læsere en god jul og et godt nytår. Det næste tip udkommer den 1. januar.
Merry Christmas and a happy new year to all of you. The next tip will be published on the 1st of january.
I have written about SMS compression before. It started in week 16/2004 and continued in week 07/2006. In this tip I tried to close the story about SMS compression, but again I learned something new. I started working on another installation where SMS compression did not work at all no matter what I tried. I contacted the storage administrators for this installation and asked them what was wrong. Every time they told me that they would investigate my problem, but they did not return with an answer. At last I got tired of waiting and started my own investigation.
If you ever run into the same problem then start by creating a job allocating a dataset with a DATACLAS set up to use SMS compression (Field compaction equals YES). Make sure that the JOB card specifies MSGLEVEL=(1,1). In the job log a warning message will be issued when the dataset is allocated and SMS compression is not set up properly. The problem is most likely occuring because dataset SYS1.DBBLIB is missing. Find out if the SYS1.DBBLIB dataset is missing on the MVS where the job was executed. If it is missing you must ask the storage administrators to install it. An IPL is needed before SMS uses a newly installed SYS1.DBBLIB dataset. If SYS1.DBBLIB is installed I cannot help you further in this area.
While investigating my SMS compression problems, I found out that SMS has two types of compression. One is called tailored compression (TCOM) and the other is called generic compression (GEN). A default compression type is selected when SMS is started and the default is typically generic. When the storage administrator defines a DATACLAS the field COMPACTION may be set to one of the values Y, N, G or T. N means no compression, Y means default compression, G means GEN and T means TCOM. When GEN is selected the same compression algorithm is used for all datasets while TCOM will build a compression algorithm dynamically (just like for DB2 compressed tablespaces) and therefore results in the best compression for the actual dataset.
I have made some measurements on GEN and TCOM. GEN saves about 25% space while TCOM saves about 50%. TCOM costs between 5 to 10% more in CPU. My conclusion is that TCOM is the best choice. If you are using SMS compression it is very expensive in CPU. With SMS compression it costs you three to four times as much to write a dataset than without compression. Another funny detail about using SMS compression is that a single volume dataset is able to extent more than 16 times.I have not reached the upper limit, but my guess is 255 extents for each defined volume. If the dataset is a two volume dataset it may extent up to 510 times and so on.