× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: accessing the records in a history file
  • From: "Al Barsa, Jr." <barsa2@xxxxxxx>
  • Date: Thu, 21 Dec 2000 14:44:31 -0500

At 07:18 PM 12/21/00 +0000, you wrote:
>What is an Encoded Vector Index?  This is a new term for me.


It's a new type of index, added in a recent release (I think 4.2 otherwise 
4.4), where an index with select omit criteria is created in memory with 
one bit (on or off) signifying that a record is to be selected or 
omitted.  As you typically can get that much memory available, this is 
tantamount to putting the select omit portion of the index totally into 
memory.  If you use SQL, and if you can use this feature, you can drop the 
query portion of time by up to 95%.  (Available only in SQL, not OPNQRYF or 
DDS, because someone in Rochester doesn't give a @#$% about existing 
users.)  An AS/400 first!

Al




>_______________________
>Booth Martin
>Booth@MartinVT.com
>http://www.MartinVT.com
>_______________________
>
>
>
>
>"Leland, David" <dleland@Harter.com>
>Sent by: owner-midrange-l@midrange.com
>12/21/2000 12:14 PM
>Please respond to MIDRANGE-L
>
>
>         To:     "'MIDRANGE-L@midrange.com'" <MIDRANGE-L@midrange.com>
>         cc:
>         Subject:        RE: accessing the records in a history file
>Encoded Vector Indexes are great for enhancing the performance of adhoc
>queries against large files.  Not sure if this fits your situation
>exactly, but I would do one over DATE, one over TIME and one over Customer
>ID.  Obviously, if you always know what criteria and sorting you are going
>to do, a regular logical would work just as well.  But if you have this
>large of a file, you need to have some permanent access paths over it that
>will make accessing the records you want faster.  This will help
>regardless of whether you use OPNQRYF or SQL.
>Dave
>-----Original Message-----
>From: booth@martinvt.com [mailto:booth@martinvt.com]
>Sent: Thursday, December 21, 2000 11:44 AM
>To: midrange-l@midrange.com
>Subject: accessing the records in a history file
>
>I'd like some insight from folks on this scenario:  There is a history
>file of records dating from 1994.  Records are added each day and now
>there are 3.6 million records in the file.  The odds of anyone going back
>to look up something in 1994 are slim but management won't purge any
>records.  Obviously the newest records are at the end of the file.  All of
>
>the logicals have the customer ID number as the first key. One logical has
>
>a key of the customer ID and then date and time.
>Each business day there is at least one and sometimes five or more reports
>
>written for all activity during some recent time period (a workshift, a
>day, a week, whatever).
>This process is becoming a performance pig; additionally there is a need
>for more function.   What sorts of suggestions do you people see as
>possible enhancements to this?  SQLRPGLE? OPNQRYF? a new Logical on date
>and time alone? #GSORT?
>Any suggestions are appreciated.  thanks in advance.
>
>_______________________
>Booth Martin
>Booth@MartinVT.com
>http://www.MartinVT.com
>_______________________
>+---
>| This is the Midrange System Mailing List!
>| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
>| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
>| To unsubscribe from this list send email to
>MIDRANGE-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator:
>david@midrange.com
>+---
>
>
>+---
>| This is the Midrange System Mailing List!
>| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
>| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
>| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator: david@midrange.com
>+---



+--------------------------------------------------+
| Please do not send private mail to this address. |
| Private mail should go to barsa@ibm.net.         |
+--------------------------------------------------+

Al Barsa, Jr. - Account for Midrange-L
Barsa Consulting Group, LLC.    
400 > 390

Phone:          914-251-1234
Fax:            914-251-9406
http://www.barsaconsulting.com
http://www.taatool.com

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.