> Date: Tue, 18 Apr 2006 10:42:58 -0400
> From: "Carlisle, D Renee" <dcarlisle AT paychex DOT com>

> I checked all that and it looks good=2E  Sg=2Econf is 
> identical, major numb=
> ers and minor number convention on the HP looks the same 
> (they don't exist =
> on sun)  no mention of compression or errors in bptm=2E  Our 
> issue is that =
> if we don't figure this out by Friday, we will be out of 
> tapes=2E=0D=0A =0D=

What makes you believe that hardware compression is not working?
Testing how many copies of a repeatable data set go to a newly expired
tape before a second tape gets used, and repeating that (same tape, same
data, same client) with 1 1.5:1 or 2:1 difference would be a clear
indication.

Didn't you mention that you had changed to a new (partitioned) library
and drives, and were getting what you suspect is no h/w compression on
one side of the library?  I'd want to know the library's contribution to
your issue by testing.

AFAIK, hardware compression is solely controlled by a SCSI command which
sets the mode; the bits for which you see in the multiple-mode fields in
Solaris st.conf entries.  That's a driver function.  On Solaris, you can
look in messages on startup and see if the capability bits and modes you
expect are what are reported.  

I'd suggest proving the compression assertion first, then getting
support people for the drive/library/drivers involved.