vhamberg@xxxxxxxxxxx wrote:

If you know - is the offline size listed in DSPOBJD that when saved with DTACPR(*YES)? If so, the other options, such as DTACPR(*MEDIUM),
can give even better compression that that, from tests I ran a while

CRPence wrote:

<<SNIP>> the Data Compression DTACPR() parameter enables
software compression which can make the saved library or object
significantly smaller [in its offline size] than its online size,
but at the cost of the CPU to effect that compression. The offline
size for an object is presented in DSPOBJD output. <<SNIP>>

Having that question asked, makes me think I was too quick to add that comment about DSPOBJD, for its use of those same _words_ that I so poorly chose to describe the results of software compression; i.e. the /offline size/ from DSPOBJD, I believe actually equates with what was the online size of the object _at the time of the save_, as opposed to the actual size of a compressed object as it appears on the media. As I understand it, the compression is performed at the /descriptor/ level for save, rather than the object level; meaning that compression would be against collections of objects, rather than against each object, which would be better for performance. I am fairly confident that my quoted implication was incorrect. Thus whatever is specified for DTACPR() would presumably have no impact on the offline size. I have no access to a system to verify the outcome.

IIRC the DTACPR(*YES) equates with DTACPR(*LOW) [doc review alludes that is mostly so], so the *MEDIUM and *HIGH would see smaller sizes on the media for objects that can be compressed using the software compression.

So then I actually go and look at the documentation, since I have actually never explicitly used DTACPR() with virtual tape... there is a *Note:* on all of the newest compression levels, that "This value is not valid for tape." Argh. I was seriously going to finally extract myself from this platform; this is just more evidence I should, without access to a system. Although a virtual tape is not really a tape, since the data for the virtual tape is expected to be used for DUPTAP to a real physical tape, then for these compression levels not being expected nor supported on tape, they can not get there indirectly via virtual tape.

So to effect the higher compression, would require the more complicated [especially for recovery] a pre-save to save files and then those saves saved to [virtual] tape. IIRC BRMS actually supports a function like this.

Regards, Chuck

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].