AS400 backup to LTO4 - hardware compression?

...which isn't even the native capacity.

Can you elaborate on what you mean by that? Basic maximum capacity is 800GB, so the 732GB value seems very appropriate.

We're using the default setting for compression / compaction to *DEV...

And can you clarify that also? When you say you're "using" it, how is it done? Do you allow the parameter to stay at its default setting, or are you explicitly requesting *DEV? I haven't tested on V5R4, but I have seen earlier releases that only honored the default for DTACPR() when it was actually specified. (And I never understood why that was so since that effectively meant that the "default" was "*NO".) It might be worth testing.

I can't find any specific info as to whether our 400 supports hardware compression on this tape drive.

It should be the tape drive controller that does 'hardware' compression, not the 400. Or if not the controller, then the physical tape drive. I would expect that you'll need to look up specs on the controller/drive models to determine capabilities.

You might post the model numbers here to see if anyone is familiar with them.

Tom

Thanks Tom.  To answer your comments: 1. Well, it's close - but since the backup had stopped and requested another tape, I expected that this tape would be pretty much full. 2. *DEV is the default setting for both compression and compaction, and that's what we've been using.  3. I agree that the hardware compression capability should be determined solely by the hardware but I thought I saw some comments that at least implied that the 400 only supported hardware compaction, not compression. But like I said, most of what I found wasn't too specific.  

I started to wonder if I wasn't over-thinking this and since I had a backup scheduled for a quieter time this evening anyway, I changed the compression parm to *YES just to see what would happen - wouldn't do much harm if it resorted to software compression. I just checked and at the beginning of the save the joblog says (approximately) "*yes was specified for *DTACPR.  Data compression is not performed when optimimum block size is used".  Guess I'll investigate that tomorrow and keep testing. I'll post back here on what I find.

I ran a small test with Compression = *YES, Compaction = *DEV and Use Optimum Block = *NO, and the files were saved as compressed.  No idea whether hardware or software compression was used.  I'd also love to know how much space they are taking on the tape, but no way to see that either, as far as I can see.  

I can't run a full test until this evening, then I'll get a chance to at least compare performance, which is critical - our overnight backups run in a pretty tight window...

Nothing good to add yet; just another general comment.

I expected that this tape would be pretty much full.

To be clear, the tape probably is "full". That is, how many individual objects are on the tape?

In addition to physical "data" that comes from the object descriptions and from the content of the objects, there is also space consumed by tape management. Some bytes are consumed every time the end of one object is reached and another one starts. There are "header" fields written in some areas of the tape for commands like DSPTAP to read -- that's how the command knows what to print and how a command like RSTOBJ knows where to find the specified object on the tape.

Further, there may be any number of spots that are below tolerances. These may be marked as unusable blocks. Given the densities of tapes nowadays, an inch of tape here and there along the length can equate to quite a few bytes. Unfortunately, no tape can ever be assumed perfect along the whole length.

Tom

Tom, sounds reasonable.

I tested using the compression parameter in yesterday evening's backup, with Optimum Blocking = *NO, and it did compress.  I did some more testing this morning and it seems that  it is using software compression - the total CPU% runs 90%+ when compression is specified (as opposed to average of 10% without compression).   I may be able to work with software compression, to a degree, but it's more or less back to the original bottom line - can the AS/400 actually use the hardware compression built into LTO drives, and if so, how?

I can answer that, Tom - the drives are 3580-004 and 3580-003 (AKA 3580-L43 and 3580-L33) both attached to a 571A-001 Storage IOA on a 2844-001 Combined Function IOP.