At 14:22 +0200 on 12/31/2008, Binyamin Dissen wrote about Re: Syncsort Oddity:
On Wed, 31 Dec 2008 13:56:20 +0200 ??? ?? ??? <[email protected]> wrote:
:>I¹ve encountered something in Syncsort, and I¹m looking for an explanation.
:>One of our users used Syncsort to copy a dataset.
:>The input file had 93386 tracks in 10 extents.
:>The output file had 64815 tracks in 2 extents.
:>Both files are LRECL=27904 BLKSIZE=27998 RECFM=VB DSNTYPE=LARGE.
:>The copy job used Syncsort¹s SDB=ON option
:>Both are allocated on the same type of DASD (3390-54).
:>When we say the 30% difference in size we used IEBCOMPR to
compare the two file, and the result was that they were identical.
:>Another test was done. This time, Syncsort was used to copy
records that had a specific value in a specific field. On the large
(Input) file, the job ran for 64 seconds. On the small (Output) file
the same operation took 7 seconds.
:>Can anyone explain this?
I would look at the raw input file and see how it was blocked. Perhaps the
program that created the file wrote smaller blocks.
Was the original file created in one pass or was it updated over a
number of runs? If the later then the problem may be that each time
you open file, you start with a new block in lieu of reading the last
block, extending it, and then rewriting the larger block before
starting a new block. There is also the possibility that the Syncsort
keeps track of the remaining space on the track and flushes the
buffer as soon as the next record would force the block to be longer
than the remaining room. IOW: You have 2000 bytes left on the track
and can write a 1900 byte record so you do so in lieu of waiting
until the block is ~27998 bytes.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
