I don't know why people talk about flat files,  I'm talking about image
dataset files which are not flat files and not 80 byte file, but have
various record size with listf database,2 of  1664, 1024 etc...  I'm more
concern about image datasets on which performance of the who system relies
on than the ordinary editor text file.  Contrary to what Adager says, it
appears from what you say that it does have some importance, right ?


Jean
Northern Credit Bureaus Inc.


----- Original Message -----
From: "Jeff Woods" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Saturday, March 17, 2001 1:17 AM
Subject: Re: [HP3000-L] I don't understand why blocking factor of datasetsis
not animportant factor anymore!!!!!!


> At  10:28 PM 3/16/01, Jeff Kell wrote:
> >With MPE/XL and MPE/iX, the smallest *atomic* disk I/O is a VSM page
> >of 4096 bytes, discounting prefetch and write cache.  So if you want
> >the most "bang for the buck" with your I/Os, optimize your blocks to
> >4096 byte boundaries at a minimum.  You're going to read/write that much
> >anyway, so why not optimize for it?  The new "optimim" 80-byte file is
> >now blocked 51*80 for a 4080-byte (16 sector) blocksize.
>
> Actually, that happens automagically on MPE/iX nee MPE/XL.  Unless the
file
> is accessed using "MR"
> (Multi-Record) access, the file system (but not Image, I think) basically
> ignores blocking factor and block sizes.  Records are packed one after
> another with no empty/wasted bytes between records (except making sure
each
> record is even byte aligned, which effectively makes all records have an
> even number of bytes).
>
> Whether you have blocking factor of 1,2,3, 51 or even 251 for an 80B FA
> file, the 52nd record will begin (80*51=) 4080 bytes offset into the the
> file and will end on byte 4160 of the file, therefore spanning the 4K page
> boundary.  Reading that record of the file will require both pages in
> memory, regardless of the blocking factor.
>
> FWIW, the exception for MR access doesn't change the way the file is
stored
> on disc, but in order to be backward compatible with the old MPE/V
> filesystem and the way MR handed records aligned on block boundaries to
the
> application, MR access has to *insert* (for a read; and conversely, ignore
> for a write) empty space between records at the end of a block to make
> records align on block boundaries in the in-memory buffer passed to and/or
> from the application.
>
> --
> Jeff Woods
> [log in to unmask] (preferred for personal posts)
> [log in to unmask] (present professional position)
> [log in to unmask] (portable & permanent, but problematic)
>