| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 344.1 | The Lowest I Can Do, But The Highest...?? | KIRK::NORTON | Charles McKinley Norton | Baseway | Thu Oct 30 1986 13:56 | 27 |
| About Finding The Lowest Key
----------------------------
Finding the lowest key is not too bad. If the key you are using to
read the file is a binary key, then start reading with its value set
to zero. If the key is a character key, then the character string
must be initialized to a null string. You cannot get a null string
this way (at least in PL/I):
character_string_variable = ' ';
character_string_variable = '';
After reading your note, I posted a note in PL/I (TLE::PLI) and Pascal
(TLE::PASCAL) notes files, because I have had occaision when this sort
of thing would be useful. You could check those notes files for
responses to my note.
About Finding The Highest Key
-----------------------------
It does not sound like you can do it easily, but your suggestion 2
certainly sounds better than reading the entire file either
sequentially, or reading with match_greater until you get an RMS$_RNF.
CMN CMPD Product Development | MLO5-2/E50 Pole 36A | 223-3590
|
| 344.2 | binary successive approximation? | PHENIX::SMITH | William P.N. (Wookie::) Smith | Thu Oct 30 1986 14:07 | 5 |
| Well, if you are going to use method 2, make sure you divide by
2 everytime you shrink your search area.
Willie
|
| 344.3 | | ULTRA::PRIBORSKY | Tony Priborsky | Thu Oct 30 1986 15:51 | 8 |
| Doesn't RMS have "key GEQ" or "key LEQ" find operations? If so,
to find the lowest key, look for the "key GEQ 'low value'" (where
"low value" has real meaning if you program in COBOL, but is zero
for a binary key (in the proper format, integer, floating etc.),
and the null string for a string key.) To find the highest key,
search for the "key LEQ 'high value'". I'm sure I used such tricks
from BASIC on the PDP-11's many moons ago. Similar things should
be available in some language that runs under VMS.
|
| 344.4 | No easy way | QUARK::LIONEL | Reality is frequently inaccurate | Thu Oct 30 1986 20:10 | 21 |
| There is no way to traverse an indexed file key in reverse order
- the indices just aren't built with backwards pointers. So for
the traditional ascending key types, you can only read sequentially
through the file in ascending order - for the new descending key
types, you can only traverse in descending order. Furthermore,
RMS provides no way to directly locate the "last" record in an index
(just as it provides no way to read the last record in a sequential
file).
The binary search method is reasonable, as long as all you want
to do is to find the "last" record. If you truly want to read the
file in reverse order (something the base note did not request,
but others have), the only real possibility is to read all the records,
store the RFAs, and then go backwards through your RFA list. VAX
FORTRAN's BACKSPACE statement uses a variation of this method.
Of course, if you have the liberty of designing the file, simply
define two overlapping key fields, one ascending, one descending,
and then you can go whichever way you desire.
Steve
|
| 344.5 | | CLT::GILBERT | eager like a child | Fri Oct 31 1986 15:00 | 5 |
| > the only real possibility is to read all the records,
> store the RFAs, and then go backwards through your RFA list.
The MATH conference on CLT:: discussed the problem of minimizing the number
of I/Os, given a limited number of RFAs that could be cached at once.
|
| 344.6 | Sideways access to highest key | THEBAY::HAYES | Same stuff, different Day | Wed Nov 12 1986 18:27 | 17 |
|
1] Finding lowest key
Do a REWIND on the key followed by a sequential GET, or a random
GET key GEQ using low values.
2) Finding highest key
As said before, RMS does not support a direct way to do this.
One method we have used in the past with ascending binary keys
is to create a another key field in the record that is set to
the complement of the key (and is therefore descending). Then
the trick is to find the lowest key (which is easy), and that
record will also contain your highest key.
John
|