Allowing the system to provide a blocking factor can be OK, but there are
many record lengths I have seen where the system gives up, and just provides
a BF of 1, which is rarely optimal. KSAMUTIL Seems to be particularly bad
here , IIRC.

I might write a little program to test this theory, say with rec len from 50
to 5k, and see what happens?
JP

> ----------
> From:         Patrick Thrapp[SMTP:[log in to unmask]]
> Reply To:     Patrick Thrapp
> Sent:         Monday, October 25, 1999 6:04 PM
> To:   [log in to unmask]
> Subject:      Re: Build command question
>
> It is not often I post here.  I lurk all the time though.  I have wondered
> about blocking factors on the HP.  Many moons ago I read some stuff about
> disc I/O & optimum blocking factors.  It was stated that at that time 8192
> bytes(8k) disc block sizes were the most efficient and quickest.  So it
> was
> considered optimal to build disc files as close to that clock size as
> possible.  To twist it up a bit MPE will read 2 physical/blocks of disc
> unless told otherwise with ;buf= parm.  So I presumed the most efficient
> was
> to use half of what was closest to 8k for the number of records per block.
> Now I wonder if any of this is still true.  Has it changed with the newer
> disc drives?  It does help with serial processing.
>
> Joseph Rosenblatt <[log in to unmask]> wrote in message
> news:F4B1826B1A21D211AEC5006008207AF402114B70@dogbert.csillc.com...
> > Carl McNamee asked:
> > >When using the BUILD command to build a fixed length flat file is there
> a
> > >way to let the system assign the most efficient blocking factor
> > >automatically?
> >
> > Yes, by skipping the Blocking parameter the machine will assign its idea
> of
> > the best blocking factor. Her is an example:
> > :build filea;rec=-10,,f,ascii;disc=100  or build
> > fileb;rec=10,,f,binary;disc=100
> >
> > I hope this helps.
> >
>