Re: Virtual tape

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
ago.

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.
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/cl/savlib.htm

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