AS400 backup to LTO4 - hardware compression?

DLyttle42
DLyttle42 used Ask the Experts™
on
We just added an IBM 3580 LTO4 drive to our old 810 (V5R4) expecting to get a weekend's worth of backups unattended.  It didn't - when I did a DSPTAP to a spoolfile, copied it to a DB file and used SQL to total the KB stored (isn't there a better way?!!)  it came to 768 million KB, or 732GB - which isn't even the native capacity.  We're using the default setting for compression / compaction to *DEV which was recommended in what small amount of info I could find on the subject.  This translates to compaction = yes, compression = no. I found some info this morning that corrected my understanding of compaction, and it looks like what I really need is to use both compaction and compression to venture into the land of more than 800GB on a tape. But I can't find any specific info as to whether our 400 supports hardware compression on this tape drive.  Software compression would probably be hopeless.  

So long story short - can I specify hardware compression and compaction, and if so, how?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
...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

Author

Commented:
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.

Author

Commented:
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

Author

Commented:
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?
...can the AS/400 actually use the hardware compression built into LTO drives, and if so, how?

Yes, depending on the "device". Without knowing your actual device and controller identifiers, there's no way for me to know.

Both DTACPR() and COMPACT() parameters allow *DEV to be specified. That's an indication of whether or not 'device' capabilities are supported. There are considerations, though. A thorough reading of the <help> text for both parameters should help clarify the circumstances.

And as earlier, there can be circumstances where the values must actually be specified rather than using default values. Commands can detect whether a default was used or not. IMO, it shouldn't affect the behavior of the command; but I have seen it happen in the past. For the SAV* commands, I've been wary of not explicitly specifying what I wanted. Unfortunately, I can't test your hardware.

Tom

Author

Commented:
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.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial