On 7/12/07, Thomas Kern <[EMAIL PROTECTED]> wrote:
TERSEd files were smaller, insignificant when dealing with a couple of blocks for a CMS file, but I think it would be significant for even a 3390-m3 and even more for the 3390-m9's that I have to deal with.
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
