Tony, Then the misunderstanding is that Compression Services as called by DFSMSdfp and DFSMSdss with HWCOMPRESS uses an LZW compression scheme, while DFSMShsm and DFSMSdss with the COMPRESS keyword use Huffman technique.
The Asymmetric cost of HWCOMPRESS I was referring to, and that apparently confused you, is the same differential for LZW that you mention below. I suspected that you did not know the difference in encoding techniques, which is why I pointed it out. I'm aware of customers with Disaster Recovery schemes that rely on restores from DFSMSdss back-ups, and spend the first 12-24 hours of the DR drill restoring data from port and channel constrained cartridge drives. HWCOMPRESS would relieve that situation and potentially speed up the restore process by 50% or more without creating a CPU bottleneck that may occur with COMPRESS. My own findings a few years ago were that dumping to disk in the absence of channel and hardware buffer saturation (i.e. disk output) using COMPRESS runs slower than NOCOMPRESS. A decade and a half ago ago when I looked at this with ASTEX trace and GTFPARS it looked like read/write overlap was disabled when COMPRESS was used. I have not run any tests with HWCOMPRESS. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Tony Harminc > Sent: Thursday, December 02, 2010 4:51 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] Hardware-assisted compression: not CPU-efficient? > > On 2 December 2010 18:20, Ron Hawkins <ron.hawkins1...@sbcglobal.net> wrote: > > Tony, > > > > You are surprised, and then you explain your surprise by agreeing with me. > > I'm confused. > > Well now I'm confused; I'm not sure how I did what you say. > > > I'm not sure if you realized that the Huffman encoding technique used by > > DFMSdss COMPRESS keyword is not a dictionary based method, and has a > > symmetrical CPU cost for compression and decompression. > > No, I didn't know anything about the compression methods triggered by > these two keywords until this thread. But I do know to some extent how > both Huffman and the LZW-style dictionary compression schemes work, > and that there is a differential between encoding and decoding speed > when an inherently adaptive scheme like LZW is used, vs a usually > static Huffman scheme. > > But I'm afraid I'm missing your point. You said that the saving in > hardware assisted compression is in decompression, and I took this to > be a claim that hardware assisted decompression is somehow speeded up > - when compared to a plain software implementation - relatively more > than is compression, and I said that I doubt that that is the case. > But if it is indeed the case under some circumstances, then I don't > see why most shops would care in most cases. > > > Finally, as I mentioned in another email, there may be intrinsic Business > > Continuance value in taking advantage of the asymmetric CPU cost to speed up > > local recovery of an application, or Disaster Recovery that is based on > > DFSMSdss restores. An improvement in Recovery time may be worth the > > increased cost of the backup. > > It's certainly possible, but I think it is unlikely to be the common case. > > Tony H. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
