Do you know how the original file was created? I would be interested if it was created by a COBOL program compiled with NOAWO.
If so, you may want to make "AWO" an shop default (and/or non-modifiable COBOL compiler option) ""??? ?? ???"" <[email protected]> wrote in message news:<bba5d76fb046794fa7f01f8e02bfc17101d4d...@jer-mail1.jer.ad.malam.com>.. . > Hi Everyone, > > I ran the Histogram utility on both files: > On the first file, the maximum block was a bit over 16k and most were about 2k. > On the second file most of the blocks were over 25k. > > So it seems the Syncsort did some major reblocking which caused the savings in both space and access speed. > > The first file has 2,630,401 blocks. Average block size 1,340 > The second file has 129,629 blocks. Average block size 27,115. > That's a 95% reduction in block count. > > Gadi > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Walt Farrell > Sent: Thursday, January 01, 2009 3:09 AM > To: [email protected] > Subject: Re: Syncsort Oddity > > On Wed, 31 Dec 2008 19:16:43 +0000, Ted MacNEIL <[email protected]> wrote: > > >>When using VB, some code will write a short block if the space remaining > in the current block is less than the DCB LRECL, even though the actual > length of the next record is unknown. > >>This results in a lot of short blocks, particularly when the LRECL is > large, as in this case. > > > >So, SYNCSORT 'repairs' this? > > Any properly written application should "repair" it, if I remember RECFM=V > processing correctly. The LRECL value in the DCB tells you the maximum > logical record length. If, when you go to write a logical record, the > current data in the block + DCBLRECL is greater than the DCB block size, the > access method will truncate the block. > > As I remember you're supposed to change DCBLRECL to reflect the actual size > of the logical record you're about to write, and then the access method can > properly fill the block. If you don't update DCBLRECL then if DCBLRECL is > close to the blocksize (as it is in the OP's case) and significantly larger > than the real LRECLs in the data set, then you could end up with a > significant number of unexpectedly short blocks. > > Presumably SYNCSORT handles all this properly, and so you get optimal > blocking, and take fewer tracks than a data set written with less than > optimal blocking. > > Note that these are very old memories... And I know nothing about SYNCSORT. > > -- > Walt ---------------------------------------------------------------------- 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
