Both files are LRECL=27904 BLKSIZE=27998 RECFM=VB DSNTYPE=LARGE Unless it's a typo BLKSIZE=27998 is 90 bytes more than needed for VB LRECL 27904.
Yet another factor. I would expect Syncsort to correct most of the possibilities already discussed. Dave Gibney Information Technology Services Washington State Univsersity -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Robert A. Rosenberg Sent: Wednesday, December 31, 2008 12:15 PM To: [email protected] Subject: Re: Syncsort Oddity 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 ---------------------------------------------------------------------- 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
