RMS: Descending key?

[Jim Strehlow]

When our application required both ascending and descending "dates", we had one column of data ascending
20040101
20040102
20040103

and the program also stored the 9's complement in another column also in ascending order.

99999999 - 20040101 = 79959898
99999999 - 20040102 = 79959897
99999999 - 20040103 = 79959896

Reading rows 79959896, 79959897, and 79959898 in ascending order yields 20040103 then 20040102 then 20040101.

(We included time also; but you get the idea.)

We had a verification utility we ran occasionally (monthly) to ensure no one accidentally "corrupted" the 9's complement data.

Jim, Alameda, CA, USA

[Hein van den Heuvel]

Well Jim, applications such as yours is exactly why RMS engineering decided to offer reverse sorted indexes. It's just to error prone and too imposing on the data design to require a dummy fields to solve this classic problem. Between the risk of data inconsistency and the waste of space the descending index clearly is the way to go, and RMS Engineering believes that for many applications the _REVerse index lookup is even a better solution (a little more work on lookup, a lot less work on insert.)

Hein

[Jim Strehlow]

Understood, however our COBOL application did not allow for descending keys at the time. It might still be a restriction(?) in COBOL.

I just wanted to illustrate an unelegant work-around for those who encounter a language-specific dilemma.

Jim

[Doug Phillips]

Hein wrote <...exactly why RMS engineering decided to offer reverse sorted indexes. . . .>

Sorry, but I agree with Jim 100%. We've had to do this in our applications, too, because it is normally only one "SEGMENT" of the key that must be inverted, not the whole "KEY".

A typical business example is a sales history file. Primary key would be:

Customer+InvoiceDate+InvoiceNumber+(...)

For inquiry, Customers should be presented in ascending sequence, and within each customer the "newest" invoices should be shown first and then in descending order. Currently, RMS offers no way to do this without creating a "complement" segment.

Likewise, I've never found a real use for "NULL" keys. Null "SEGMENTS" would be nice, but if an entire key can be null, then the key and probably the entire data record structure is IMHO either very poorly designed, or possibly the application using such a file doesn't live in my world.

Doug

[Hein van den Heuvel]

Doug wrote:

'Currently, RMS offers no way to do this without creating a "complement" segment.'

Right. This is true. Somehow RMS Engineering got the business justification to do what was planned all along: a data-type per key segment. The XABKEY already has an array for xab$b_typ, just like pos and len, but it is not being used :-(.

Doug also wrote:

"Likewise, I've never found a real use for "NULL" keys. Null "SEGMENTS" would be nice, "

Probably true for you, but this is less clear cut to me.
What is clear cut that RMS _should_ simply have had full null key value string, not just the byte. I think this did not happen in a desire to stay with the existing in memory XABKEY and on-disk KEYDEF ($KEYDEF in sys$Library:lib.mlb) structures.
A full function null key would need a 255 byte additional field.
But I have a hard time imagining a multy segment key (cust+datge+invoice) with lots of records in the file having the same null/dontcare value. That sounds like wrong design to to me, mixing record types too much. When you mix text and binary segments, it woudl be hard to define a valid single-byte null key, but I do not see that much in practice either, precisely because rms does not allow one to mix types. That leaves the ascii number strings mixed with text where perhpas a space is not valid for the numbers, and a zero looks odd for the text.

Cheers,
Hein.

[Doug Phillips]

Hien wrote: >>But I have a hard time imagining a multy segment key (cust+datge+invoice) with lots of records in the file having the same null/dontcare value.<<


I suspect the null key came about because it was envisioned that a file could contain lots of records where some field's value would be assigned post record creation and used as a secondary key. There would then be lots of records with a blank or zero secondary key value that would add to the dreaded duplicate key overhead if not excluded.

However, as a very wise man has said;-), duplicate keys should be avoided whenever possible. So, part of the secondary key should contain something else that would make it unique. SO...

Null keys aren't very useful. Null "segments" make more sense. I'd rather see:

"SEGn_NULL" with a value definition that would cause exclusion of index entries that matched the value in that segment, or better still,

"SEGn_EQUAL" with a value definition that would cause exclusion of index entries that did NOT match the value in that segment.

I guess mixed ascending and descending segments within a key would be way too much to even mention:-)

Doug