rms index key values

[Tony Gallati]

Is it possible when defining an rms key within an fdl to allow uppercase and lowecase letters to be treated with the same match value.
Example: a 25 byte key field for name will access the same whether reading by the key
Massachusetts or MASSACHUSETTS
A VMS Search would bring up either field as being the same, but I will get 2 different key values when reading by the 25 byte rms defined key.

[Hein van den Heuvel]

Yes it is possible, but standard RMS keys are case blind.

String keys are just arrays of 8-bit unsigned chars.

You can however use COLLATING keys.

that should work but possibly more hassle than you want. There is very little experience with collated keys out there.

You may want to store UPCASED, and match upcased.


http://h71000.www7.hp.com/doc/731final/4506/4506pro_006.html#apps_collating_keys_ex


http://h71000.www7.hp.com/doc/731final/4523/4523pro_018.html#170_xabb_dtpfield

http://h71000.www7.hp.com/doc/73final/6027/6027pro_008.html


Hein.

[Hoff]

If I'm not inclined to tangle with NCS and collation (and there seem few source code examples of this stuff around; Hein or I should probably post one somewhere), then (for simplicity) I usually upcase the search keys in an RMS indexed file, and also tend to enforce use of either space-padded or null-padded strings, depending on the environment.

Depending on what you're up to here, a soundex key can be useful, too.

[John McL]

Is it too "expensive" to store in the record both an upper case version to use as the key and (presumably) a mixed case version for presentation?

This will mean that you can correct the case used on data input and have a standard version of each entry. It also saves you trying to reconstruct the "correct" version at run time - think of Anglo surnames with Mc, Mac or O' (or Dutch de) at the start where the next character should be upper case ...

[John Gillings]

Tony,

Don't forget, storage is cheap. When defining a record it's often helpful to make artificial keys based on other fields, rather than trying to use data directly. You get a bigger record, but it can help in semantics. Assuming "Massachusetts" is a real example, consider storing the record as:

KEY field Data field
MASSACHUSETTS Massachusetts other stuff

So, the data retains case as entered, but the key is always upper cased. When doing a lookup, upper case the search key, but use the case preserved data field when printing the record.

As long as all the code that deals with the file is isolated into a module, you can easily enforce formatting and case rules without the application being aware.

[Hoff]

And for new or substantially-updated applications, UTF-8 for data storage (which has better international support) and UTC for time are both good candidates for inclusion.