Hardware compression has been available on the iSeries 400 for some time. But did you know that software compression...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

Hardware compression has been available on the iSeries 400 for some time. But did you know that software compression...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
is also available, and it's relatively easy to use?
IBM offers two algorithms: simple terse (whatever that is) and IBM LZ1. The latter is IBM's patented implementation of the Lempel-Ziv algorithm, used in WinZip and pkzip. In my experience, this algorithm is much the better of the two, so I'll cover LZ1 here.
To use compression, you need to provide the address and length of the source and result strings, and the algorithm number. (1=Simple Terse, 2=IBM LZ1.) These details are placed in a data structure, known as a template. The address of the template is then passed to the MI builtin function.
The compress function will populate the result field, and place the length of the compressed string in CompressLen. In this example, CompressLen = 65. That's an excellent compression ratio, but this a rather contrived example!
Decompression is similar. Note that we do not need to provide the source length or algorithm number. The decompress function can determine these from the compressed string.
The decompress function will populate the result field, and place the length of the decompressed string in decompresslen. You must be sure to provide a long enough result field. Often you will know the original string length, so this will not be a problem.
So when is compression useful? Recently I needed to store an audit trail of seven days' worth of data (approximately 70000 records) as received via MQ Series. The data arrived as one long string, 10800 bytes long. That's an uncompressed length of over 700MB. The data contained lots of blanks and zeroes, and was an ideal candidate for compression. By storing the compressed data in a variable length field in the audit file, I was able to reduce the storage requirements by a factor of 15. Very useful and quite straightforward!
* Prototype for MI builtin function: D Compress pr Extproc('_CPRDATA') D RcvrPtr * Value * Compression template: D Rcvr ds D SourceLen 10i 0 Inz(%Size(Source)) D ResultLen 10i 0 Inz(%Size(Result)) D CompressLen 10i 0 Inz(0) D Algorithm 5i 0 Inz(2) D 18 Inz(*LOVAL) D SourcePtr * Inz(%Addr(Source)) D ResultPtr * Inz(%Addr(Result)) D Source s 2400 Inz(*ALL'The cat sat on the mat. ') D Result s 2400 C CallP Compress (%Addr(Rcvr)) Decompression example: * Prototype for MI builtin function: D Decompress pr Extproc('_DCPDATA') D RcvrPtr * Value * Decompression template: D Rcvr ds D 4 Inz(*LOVAL) D ResultLen 10i 0 Inz(%Size(Result)) D DecompressLen 10i 0 Inz(0) D 20 Inz(*LOVAL) D SourcePtr * Inz(%Addr(Source)) D ResultPtr * Inz(%Addr(Result)) D Source s 2400 D Result s 2400 C CallP Decompress (%Addr(Rcvr))
MORE INFORMATION ON THIS TOPIC
The Best Web Links: tips, tutorials and more.
Ask your programming questions--or help out your peers by answering them--in our live discussion forums.
Ask the Experts yourself: Our application development gurus are waiting to answer your programming questions.