From: DL Phillips [whohe@whoever.com] Sent: Wednesday, May 05, 2004 12:24 PM To: Info-VAX@Mvb.Saic.Com Subject: Re: An RMS feature I wish for "Bill Todd" wrote in message news:... > "DL Phillips" wrote in message > news:af0dc2ea.0405041331.5ae2624a@posting.google.com... > > RMS/FDL KEY definition, a way to index only records having a specific > > matching string or value. Something like: > > > > KEY n > > [...] > > IDKEY_VALUE "01" > > IDKEY_POSITION 20 > > [...] > > > > That would index only records having "01" in position 20. This would > > be the exact opposite from a NULL_KEY definition. It could be called > > anything, IDKEY was just what popped into mind. > > > > I've only wished for this for a couple of decades. Some files cannot > > be "normalized" and must use record type codes. > > > > Just a wish said outloud. Every time I have to setup an alternate key > > to access a specific record type I cringe at the wasted indexing. > > Today I cringed twice;-) > > I'm curious, and not sure I understand. > > The example above appears to be specific to a particular key - i.e., you'd > still need a separate alternate index for each record type that you wish to > index. True, you need space defined in every record for every such key (all > but one of which will contain the defined null key value for a given record > type), but unless there are a great many of them this should not be too > burdensome, and the RMS record compression facilities should help there as > well. > > Another option is to use your record type code as the most significant byte > of a single, shared key: this results in a single alternate index > partitioned by record type. If some records don't want to be indexed at > all, just duplicate the type code byte such that unindexed records can use > the null key value in the leading key byte. > > I don't know whether it was the advent of Rdb that more or less stopped RMS > development, but a lot of interesting potential features that we talked > about back around 1978 - 80 just never got implemented (though key > compression and IIRC single-key, no-RFA files did). One such (I think, > unless it's something I came up with later) was the ability to associate > arbitrary keys (potentially including multiple instances in the same index) > with each record - an 'external key' mechanism rather than the current > embedded-key variety, which among other uses and in conjunction with a > no-primary-key file, where records were organized in a flexibly-managed > bucket chain, would have provided the kind of multi-record-type support that > I think you'd like. > > - bill Bill, & Hein. I don't ever expect to see this feature but I sure didn't think it would need further explanation. I'm suggesting this in addition to and as an expansion of all of the other KEY definitions (for alternate keys, not KEY 0). Yes it is specific to one key, just as NULL_ and SEG_ and other KEY section defs are specific to each KEY n definition. Yes you would need more than one alternate key definition if you needed to access a file by more than one record type. In my example, the [...] means whatever other def's you need for the key. The IDKEY defs say: Only create an index entry if the record contains "01" starting at position 20. "01" and 20 could be anything else. "AB" and 258 or whatever. Think something like the DCL search command. You only get the records you need. Now, for a "non-normalized" RMS file (i.e. not built in a relational manner) to access all header records by a field unique to that header, the record type code will be defined as a segment primary to the specific header field you're after and in addition to other primary key fields. RMS will index every record in the file, and most of the indices will be garbage because the data in the matching position of those records could be anything, but it isn't what we want. The keys would be partitioned, yes, but only a small percentage would be useful. Another way to deal with this programatically (if file size dictates) is to create secondary file of the keys for the records of interest. This involves the overhead of keeping these "cross-reference" files in synch, but that's one way we've done it. Some files with multiple records types are defined standards and we have no control over their format, like: EDI X12 (Trading partner ID), (US)IRS/SSA MMREF (Employer ID), to name a couple. Sometimes these files can get very large, sometimes they're small. Small and Large are relative terms, naturally. Many files are so established and surrounded by so many lines of program code that to normalize their structure or convert them to a DB format would just not be affordable or practical. Customer order processing files are a common example. This is not a feature I just "invented". Some old primitive systems had this. One comes to mind: When I started programming on VMS I was also doing quite a bit of work on a Singer System Ten. The System Ten had it, RMS didn't and that surprised me. It seems like MicroData Reality had this, too, but I'm not sure about that. That was a Pick based system, I think, and all I remember was that it had a lot of very impressive features. Anyway, thinking out loud again, maybe rather than IDKEY, how about "SEGn_MATCH" where you would define the value that must be in that segment position in order for the key to indexed. Then, I guess SEGn_LENGTH could be optional if a string match value was defined. Oh, well. Sorry if I haven't made myself clear. Like I said, it was just a wish said aloud. I agree, Bill, RDB has probably limited RMS new-feature development. And, Hien, I'll try to read your tech articles in greater depth, maybe someday if my brain grows big enough I'll understand them. But, I think what I've suggested fits your goal of reducing overhead for record stores. Doug