HP3000-L Archives

October 1999, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Joe Howell <[log in to unmask]>
Reply To:
Date:
Tue, 19 Oct 1999 07:34:25 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (38 lines)
Not to sound like an advertisement, but......

<<PLUG ALERT>>

I ...NEVER... serially read a data set.  98% of my applications since 1990 are
OLTP
and require sub-second response time.  I investigated Omnidex (by DISC) and
Superdex (by Bradmark) and chose to make use of the Omnidex keyword and
(most importantly in my case) sorted indexing on top of our T-Image databases.

Yes, this means my clients have had to pay support to an additional third party
vendor since 1990, but their user communities have enjoyed truely sub second
response since that time.  This started back still using classic machines.  When
we moved to a 957 in late 1991, the few batch jobs I had finished so quickly
that I started
receiving trouble calls due to jobs "blowing off".  Turns out they were working
fine. Its just that making use of the predefined access paths optimized for
the access the applications needed most frequently cut run times to a true
minimum. They ran so fast the users thought they must have failed.

In later years, TPI hooks were added to Image, and I assume (but haven't looked
lately) that Generic-Partial Key lookup was added also.  I know it was talked
about
in IPROF meetings several years ago.

In summary, If you have not looked into alternate indexing (keyword and sorted)
for image, you might want to try it.  My clients love it.

<</PLUG>>

Joe Howell
HIS COmpany
Valparaiso, FL

Onsite at International Paper, Savannah GA
[log in to unmask]
800-966-5284 Ext 4272

ATOM RSS1 RSS2