Achieve Significant Compression With zEDC
This is part one of a two-part series on a compression feature new to the z/OS 2.1 operating system, zEnterprise Data Compression. Read part two here.
Would you rather pay for 10 disk drives or five disk drives? What about space? Do you think there is any chance the 10 disk drives could take up more space? What about using more power, cooling or disk management time? There’s also the time and cost to read all of that data. What do you think the chances are that you can read all the data off 10 disk drives faster than you could read all the data off five disk drives?
One solution is to not have lots of data. If your business plan is never growing, you’re never increasing your customer base, you never have very much inventory or your inventory never changes; you never have a reason to increase the amount of data that it takes to run a business. In fact, you could even plan on reducing the amount of data you have to deal with. All of these are excellent disk-saving techniques and make for a wonderful going-out-of-business strategies.
On the list of more practical business solutions, you have the option of taking all that data that must be maintained and held on to, and squeeze it into fewer disk devices, make the data smaller. There are solutions available that work much better than possibly using Alice’s technique of making things smaller through the use of mushrooms. The magical technique being referred to here is, of course, compression.
Compression’s Rise in Popularity
Compression is fascinating. It’s been around in one form or another as long as we’ve had data. In the land of DB2, we started out with software compression. A compression program would be installed in place of the EDITPROC to compress your data as it was added to DB2. At one point, compression software could be a company’s claim to fame. It worked, it was impressive and it saved disk space. However, it could be expensive in terms of CPU usage. You used compression when you absolutely needed to reduce the size of a table space. In some circles, compression was considered a necessary evil.
However, in December 1993, that changed. Whether you called it hardware-assisted compression, Enterprise Systems Architecture compression or DB2 compression, it became an important and integral feature of DB2 for z/OS. Because of the hardware assist, the cost of the compression process was significantly reduced. Compression began to gain in popularity. Today it’s almost standard practice to compress anything of size. In fact, today it’s more the exception to find a table space that doesn’t take advantage of compression. Of course, if saving disk space wasn’t good enough, you could even save a little CPU by reducing the number of I/Os required to read compressed data into DB2’s buffer pool.
What we use in DB2 is a terrific example of hardware to significantly reduce compression cost for data using the compression call instruction. Read more about DB2’s data compression in my three-part blog post starting here.
Now, if DB2 hardware compression works so well, it begs the question why we need another form of compression.
New Compression Introduced
In July 2013, IBM announced enhancements to the IBM zEnterprise EC12 (zEC12), the IBM zEnterprise BC12 (zBC12) and the z/OS 2.1 operating system. In that set of announcements, there was a new feature one could buy called zEnterprise Data Compression (zEDC), along with a new Peripheral Component Interconnect Express (PCIe) hardware adaptor called zEDC Express. zEDC is new to z/OS and a bit different from all the compression stuff this old DB2 guy has grown use to using during the last 30 years.
This new type of compression that has suddenly rekindled my interest in compression, not only works differently but has a completely different use case. DB2’s compression works at the row level and uses a dictionary. zEDC works at the page or data set level without the need for a dictionary; zEDC uses a different compression algorithm that has minimal CPU impact. The z/OS component System Management Facility (SMF) is the perfect candidate to take advantage of zEDC.
How exactly does this new thing called zEDC work? The concept of compression I understand, but with zEDC, in order to take advantage of the projected reduction in resource consumption and to realize the improved disk utilization—use less disk space as a result of compression—there is actually the combination of two components necessary.
On the software side you’ll have to have the zEDC software feature that’s available in z/OS 2.1. The second part is the hardware accelerator, or the zEDC Express adaptor. With both of these pieces, you can achieve reduced CPU and disk usage. Read that last sentence again: With zEDC you can achieve significant compression while also appreciably reducing your CPU usage, with all this not just for the compression portion but also reducing write overhead.
zEC12 or zBC12 are hard requirements for the implementation of the zEDC Express feature; processors to the zEC12 or zBC12 cannot use zEDC Express. However, earlier release of z/OS (specifically, z/OS 1.13 and 1.12) will support software decompression only for the SMF dump program IFASMFLD when the proper keywords are specified and APAR OA41156 has been applied.
Don’t read over that word decompression too quickly as there is no compression support in any z/OS flavor prior to z/OS 2.1. zEDC in its simplest implementation can be set up via a DATACLAS policy.
A New Processor
Arriving along with zEDC is a new processor, something that behaves similar to a specialty engine (IFL, Integrated Coupling Facility, System z Application Assist Processor, System z Integrated Information Processor, and the non customer definable SAP). However, being a processor is where the similarity ends. You see, this particular processor has one, and only one, purpose in life. It is not something a customer has to pay for, is not usable by the customer, nor is it visible to a customer and is not something the customer can define.
The new processor, the integrated firmware processor (IFP), supports the native PCIe features. In our case, the PCIe feature that’s of interest is zEDC Express. 10GbE RoCE Express is the other PCIe feature supported by the IFP. I’m told that the IFP’s usage is very small, meaning that the IFP has a minimal multiprocessor (MP)-effect impact on the overall system capacity and performance while allowing movement of some CPU cost off of the general purpose processors (CPs) and on to the IFP. Up to four compression cards can be share by a partition and is limited to a total of 16 partitions.
Easy Implementation With zlib
What’s going to make zEDC such an easy implementation for IBM, clients and almost anyone? In a single word: zlib. zlib is also what’s going to make zEDC almost invaluable.
You see, zlib is a no-charge, license free, general-purpose lossless data compression library published in 1995 by Gailly and Adler that is now considered an industry standard. Its data format is portable across Linux, z/OS, Mac OS X, iOS and gaming console platforms. It’s used in all sorts of places, many of which you probably are already familiar; e.g., PKWARE ZIP and Secure Zip, many browsers, MQ, zSecure console suite, Java jar files and the list goes on. zlib is very popular and highly used.
The open-source zlib library available via z/OS Unix System Services is supplied with z/OS v2.1. zEDC uses zlib as a wrapper that can transparently call zEDC and zEDC Express. This allows any products that currently link zlib into their routines, or plan to in the future, the ability to take advantage of zEDC with minimum effort. Basically, anyone can set up to use zEDC if zEDC is available.
Keep in mind that zEDC is a z/OS 2.1 feature that requires a zEC12 or zBC12 (although decompression is available in z/OS 1.12 and z/OS 1.13 via APAR mentioned earlier) that in its simplest implementation can be set up via a DATACLAS policy.
Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.
comments powered by