Mike is correct; MPE/iX uses prefetching and IMAGE is all mapped I/O.
MPE/iX gets pages of data from disk in multiples of 4k byte blocks. When
earlier I asked for a LISTF,2 of the master dataset, what I wanted to see
was the record size. This record size should be at 2048W or a factor
thereof, like 512 or 1024. This means that when MPE fetches IMAGE blocks
(records,) it will bring in complete blocks at one time and be able to
decipher them in memory. It has been my contention for a long time now (15
years?) the best record size for an IMAGE dataset is 2048W. If you can fit
multiple IMAGE records into on 2048W MPE record, you are doing yourself a
favor.
Until such time as we know the size of the master record and the size of the
dataset record, all this discussion is for naught.
But it is entertaining.
Denys...
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf
Of Mike Hornsby
Sent: Friday, February 08, 2008 3:36 PM
To: [log in to unmask]
Subject: Re: [HP3000-L] Howmessy
Gilles Schipper wrote:
> Wow.
>
> That's a new one for me.
>
> I've used Howmessy for many years with outstanding success and have
> seen very meaningful results as the results of making adjustments
> based upon its reports.
>
> I respect and admire your HP3000 expertise, Mike, but I very humbly
> question your claim about Howmessy's "meaningless"-ness.
>
> Please explain.
'The statistics you are looking at for a master data set are nearly
meaningless '
You have generalized my specific observation for the small master data
set to any information provided by Howmessy.
MPE/iX uses prefetching, and Image uses mapped file IO. This innovation
minimizes most of the discussion of
'blocks' and 'elongation' for master datasets. For detail datasets the
Howmessy chain information is more valuable, but
still one would have to factor in the media record size and the
corresponding number of entries that got prefetched.
If a small master dataset is at the heart of an application, such as an
item master, it will be prefetched and stay
in memory. The only factor for DBGET regaurding the secondaries would be
the cpu time related to parsing out the pointers.
DBPUT on a master dataset would have other issues and one would need to
factor the max blocks by the media record
size and number that fit in a prefetch.
TGIF,
Mike
>
>
> At 03:14 PM 2008-02-08, Mike Hornsby wrote:
>> Jim Phillips wrote:
>>> So, I ran Howmessy on the main data base here and the very first
>>> data set looks very suspicious. The report for this manual master
>>> shows 78% full (19381 entries, 24859 capacity), 30.3% secondaries,
>>> maximum blocks=190, blocking factor=1, maximum chain=7, average
>>> chain=1.43, standard deviation=.70, expanded blocks=1.43, average
>>> blocks=2.30, elongation=1.60 and, are you ready for this,
>>> inefficient pointers=100%!
>>>
>>> My first thought was to increase the blocking factor (my thinking
>>> is with a blocking factor of 1, every pointer must cross a block
>>> boundary). I could also increase the capacity somewhat to get the
>>> load factor down to 70% or so.
>>>
>>> What does this august group recommend?
>>>
>>>
>>
>> Unless you think that you are going to add another 2k entries in the
>> near future, I would not advise doing anything.
>> Howmessy has not been updated for MPE/iX. The statistics you are
>> looking at for a master data set are nearly meaningless.
>>
>> Beechglen has a free utility DBLOADSX, This program provides fast
>> native-mode analysis for complete databases or individual datasets.
>> The lattest version also reports DDX, MDX, and Btree information.
>> http://beechglen.com/mpe/dbloadsx.html
>>
>> TGIF,
>>
>> Mike Hornsby
>> CTO/CoFounder
>> Beechglen Development Inc.
>> 513-922-0509 x31
>>
>> * To join/leave the list, search archives, change list settings, *
>> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Free Edition. Version: 7.5.516 / Virus Database:
>> 269.19.21/1265 - Release Date: 2008-02-07 11:17 AM
>
>
----------------------------------------------------------------------------
---------------------
>
> Gilles Schipper
> GSA Inc.
> HP System Administration Specialists
> 300 John Street, Box 87651 Thornhill, ON Canada L3T 7R4
> Voice: 905.889.3000 Fax: 905.889.3001
> email: [log in to unmask] web: http://www.gsainc.com
>
----------------------------------------------------------------------------
---------------------
>
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
