Re:

>  2) When reading a file that has been opened with either NOBUF or MRNOBUF

> In case 2, above, the blocking factor is used to insert fill characters into
> the "block" of data that is returned to the caller, so that it looks exactly
> like it did on MPE/V, when data actually was stored in a block-by-block
> basis.

I'd forgotten about that padding.

> So in the one case of MRNOBUF access, it is best to try and specify a
> blocking factor which allows the least amount of "wasted space" per "block".

Note that the "wasted space" is solely in the user's program buffer ...
not on disk!   (Or, it's on the transport-mode STORE tape ...but still not on
disk on MPE/iX)

Despite the padding, the performance difference didn't show up in tests
I just ran & posted.
...but then, that's probably because my blocks were all multiples of 128 words
(256 bytes), and therefore had no padding.

Ok...I've just re-tested with record size of 200 bytes.

   build foo; rec=200,<XXX>,f,binary;disc=10000,1,1
   (entire file in memory)

   Blockfactor  CPU     Elapsed
       1        0.877      1
       2        0.861      1
       4        0.894      1
       8        0.877      1
      16        0.882      1
      32        0.874      1
      64        0.885      1
     128        0.890      1
     255        0.869      1

In each case, I'm doing MR NOBUF reads about about 30K words (60K bytes)

SS
Stan Sieler                                           [log in to unmask]
www.allegro.com/sieler/wanted/index.html          www.allegro.com/sieler