On 24 May 2007 18:20:54 -0700, in bit.listserv.ibm-main you wrote: >I believe both sequential and at least some VSAM datasets can utilize >compression in their representation on DASD. This requires that the >datasets be SMS-managed and be assigned a DATACLAS that defines the >dataset as "extended format" and "compressed". This is enabled on the >individual dataset level based on DATACLAS attributes and not on a >volume level. To determine whether it was in effect, you would have to >check the DATACLAS associated with the dataset and then look up the >attributes your installation has assigned for the Data Class to see if >it specifies compressed extended format.
Depending on your actual spinning DASD, compression may be counter productive for actual disk utilization. It can save logical space and cache space but if the controller is compressing the data in cache to store it on disk, this may foul up the compression algorithm. > >The compression/decompression is done by the I/O access method routines >using special hardware compression assists associated with a Central >Processor in a manner that is almost transparent to the application >program, which still thinks it is reading/writing records and blocks in >uncompressed format. The only part that is not transparent is that the >maximum block size that can be declared and still fit n blocks per track >is reduced by an additional 32 bytes of control information that is >added to each extended format block (not accessible to an application >program). > >Whether it makes economic sense for a specific application or >installation depends on many factors, and your mileage may vary. It >does cost extra CPU time, so if you are in a CPU-constrained shop (or >concerned with what extra CPU usage does to your software costs) and >have plenty of DASD, it might be a hard sell to justify. We look at it >every several years to see if the performance has significantly >improved, but I haven't had a chance to re-test since we migrated to a z9. > >IBM tape subsystems from 3490 on (it was an optional feature on 3480's) > routinely do hardware data compression within the tape subsystem >itself and merge logical data blocks into super-blocks to optimize tape >media usage, all at no cost of additional mainframe processor time. >This approach has not been taken with DASD subsystems, I suspect because >there are so many places that knowledge of track/cylinder capacity is >used in significant ways, plus the potential that concurrent users of a >dataset may be dependent in some way on a logical block corresponding to >a physical block on DASD to properly control serialization and >update-commit strategies. > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
