Alfredo,
 I think Steve, Jerry and your own Ken had shared good ideas about Prefetch.
 After our first piece in the May issue of "What's Up Doc?" we ended up
 following it up with this piece in the July issue.
 
Add me to the list that suggests not doing it 'automagically'.
 
/paul
 
==================================================================
 
IMAGE Prefetch Bug -- But Which O/S Versions?
 
After recommending that you enable IMAGE prefetch in our last newsletter, we
discovered that some versions of MPE/iX had some problems.  One of our
customers was getting "CORRUPT DBG DISABLED; POTENTIAL DAMAGE; ONLY DBCLOSE
ALLOWED" messages.  Pretty scary!   HP said the messages were bogus and
advised the customer to disable IMAGE prefetch.  When this was done, the
problem went away.
 
When should prefetch actually be used?   As per Marguerite Bryan of the HP
Response Center in issue #20 of the IMAGE Support Newsletter, you may use
prefetch when
 
1.   The system has adequate memory available to manage the increased data
   page locality as well as adequate processor capability to handle increased
   concurrency of processes.
 
2.   The application makes numerous calls to DBPUT, DBDELETE, or most recently
   DBUPDATE to critical items.  Other TurboIMAGE intrinsics only read or
   update data, not pointers or counters where multi-block access is a real
   issue.
 
3.   As PREFETCH is intended to increase database concurrency, multiple users
   must be processing data before the benefit can be realized.  Prefetching
   data blocks offer little or no benefit to single processes executing
   against a database.
 
The problems have been found in TurboIMAGE versions C.04.06 through C.04.08 on
MPE/iX release 4.0.  This problem is documented in detail in SR 5000-668673
and can be fixed by installing the patch TIXFX04 (TurboIMAGE C.04.09).
================================================================