X-no-Archive:yes
Earlier today I answer Juan's question, privately it seems.  I reproduce my
answer here.

You do not have wasted space on flat files due to record size.

My main point for Image is that you have to create a block, because that is
how Image works currently.  Before MPE/XL (and later MPE/iX) the I/O for
Image was all done with FREADDIR and FWRITEDIR.  Using the 24/8 address
notation for an Image record, where 24 bits are the block number (or MPE
record number) and 8 bits for the image entry within the block, an FREADDIR
with the block number would retrieve the entire MPE record, containing the
bit map, followed by all the media records for the Image entries of that
block.  Once the Image record was in memory, Image could get to work and
decipher the bitmap and pull out the appropriate Image entries, or write
the appropriate entries and diddle (sorry for the technical term here) the
bit map.  An FWRITEDIR would then post the MPE record to disk.

A LISTF of the dataset would show the actual length of the MPE record.

Now, with MPE/iX, all Image I/O is performed as mapped I/O.  This means
that given an Image entry number, the block size and the block factor, one
can compute the exact word offset from the beginning of the file where the
Image entry starts.  Since you always want to have the bitmap in Image
processing, you then always point to the beginning of the block by
multiplying the block number by the block size.  The result will be the
address of the beginning of the block and so, when you 'touch' that address
MPE will bring back, I believe up to three pages of Image blocks.  So, if
your Image blocks fit evenly in 512, 1024 or 2048, the 3 pages (if it is 3
pages) will contain complete Image blocks.

This is empirical and I have not been able to prove overall performance
improvements to my satisfaction.  In the MPE/V days, a blocking factor of
2048 was excellent, because it also matched the hardware.  The disk
transfer were 4096 bytes and the hardware disk caching was geared to that
size.  We also used to block our MPE files and KSAM files the same way and
witnessed tremendous performance improvements.


Kind regards,

Denys. . .

Denys Beauchemin
HICOMP America, Inc.
(800) 323-8863  (281) 288-7438         Fax: (281) 355-6879
denys at hicomp.com                             www.hicomp.com



-----Original Message-----
From:   Mike Hornsby [SMTP:[log in to unmask]]
Sent:   Monday, 12 April, 1999 3:26 PM
To:     [log in to unmask]
Subject:        Re: DB blocking factor education.

DBSCHEMA automatically determines the number of data records that fit in a
block that makes the best use of disk space under the BLOCKMAX specified.

WHY NOT SIMPLY SPECIFY A BLOCKMAX=2560?

The data set entries are fetched from the disk into 4096 byte pages that
consist of the above blocks. When selecting BLOCKMAX you are trading off
disk space utilization versus fetching the block into multiple pages, and
the possibility of separating the bit map on the front of the block from
data at the end of the block.

 Mike

--