HP3000-L Archives

December 1996, Week 5

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:
Mark Landin <[log in to unmask]>
Reply To:
Mark Landin <[log in to unmask]>
Date:
Mon, 30 Dec 1996 16:12:18 GMT
Content-Type:
Text/Plain
Parts/Attachments:
Text/Plain (45 lines)
In article <[log in to unmask]>,
[log in to unmask] says...
>
>We use our HP 3000 for a third-party pharmacy prescription
>application.  It's really a turn-key system which is why I am a
>relatively unsophisticated MPE person.  We have a single IMAGE databse
>with over 30 detail sets that contains almost a million entries in the
>largest set.  The problem is that most of the "fields" are not usable
>as key fields for QUERY reports which means that a serial read takes
>15-20 minutes and consumes 100% of the CPU and 85% of the disk
>resources which means that these reports can really only be run after
>normal working hours.  The vendor has indicated that use of ANY
>indexing scheme that modifies the database by so much as a single byte
>will void our software support contract.  Since this application is
>mission-critical to our department I have taken this warning to heart
>and not tried to use programs like Omnidex.  What I am wondering is if
>there are any ways that a relatively non-tech person can set something
>up as an indexing scheme to get around the inherent lack of keys.  I
>am getting more and more requests for ad-hoc reports that I can't
>respond to without  more keys.  I have even wondered if the future
>release of b-tree indices will help me, but I think they will only
>exist for IMAGE/SQL databases.  Any and all help appreciated.
>
>Kirby Stiening, Pharmacy Information Systems Supervisor
>University of Virginia Health Sciences Center
>Charlottesville VA
>804-982-0373

YOu may have a couple of choices:

1) KSAM files could be used to be external indices into your data. You would
have to insure that the KSAM files are kept up-to-date somehow. This could be
as simple as a nightly re-indexing job or as complex as modifying all your DB
update routines to also update the KSAM file appropriately, depending on how
static the data is.

Your KSAM records would have basically two fields: the first field would be the
item or attribute in the dataset that you want to index (let's say it's
price...) and the second field would be the primary key (say, product code). If
you wanted to index by more than 1 attribute, you would need at least 3 fields
per record: 1) index item name, 2) index item value, and 3) primary key value.

 2) Buy SUPRTOOL and continue doing serial reads....but many times more
quickly. SUPRTOOL is a very handy product. Get it from Robelle.

ATOM RSS1 RSS2