At this point I am not concerned with CPU cycles spent on compression or on network bandwidth. I am trying to use PIPEDDR (with my own kludge for TAP E output). The CPU cycles for compression would not be as much of a problem as the CPU cycles I want to spent on data ENCRYPTION prior to writing out to
tape. If my customer ever gets a backup data center of their own, I will look into PIPEDDR (with encryption) for network transfer of backups. /Tom Kern /301-903-2211 On Thu, 12 Jul 2007 17:45:25 +0200, Rob van der Heij <[EMAIL PROTECTED]> wrote: >Depends on what your criteria are. Do understand that "terse" takes >quite some CPU cycles and depending on the resources available, that >may become the bottleneck. When you transfer large chunks of data over >long haul connections there will be latency issues that get important >(and it may be more attractive to run multiple streams). And you may >also find that your mainframe connection was improperly defined in the >switch with an asymmetric bandwidth capping... > >Long before Bruce did his PIPEDDR, I wrote my IP-DDR package (after >all, I got the track* stages for my birthday). It's initial raison >d'etre was to keep a copy of the RACF database on a DR site. Since our >RACF database was defined rather big, only a small number of tracks >would be changed in a day. So my IP-DDR used a per-track checksum that >was exchanged between both ends to decide whether a track should be >sent at all. The per-track approach also allows for doing multiple >streams in parallel and use a connection only for a small amount of >data (to fool the bandwidth shaping). The checksum thing turned out to >be very helpful also to restart a transfer after something interrupted >it. > >Since it's not uncommon to have disks partially "empty" when you need >to transfer them, the Piper created "tracksquish" to have cheap >compression of empty tracks. I also used that a lot to keep a copy of >a Linux disk with empty file system. > >I recently talked to John about the value of having zlib stages, but >it did not happen yet... > >Rob
