[Info-vax] The best VMS features, was: Re: openvms renaming file

[johnwallace4 at yahoo.co.uk]

On Wednesday, 30 May 2018 02:32:03 UTC+1, Craig A. Berry  wrote:
> On 5/29/18 6:54 PM, Johnny Billquist wrote:
> > On 2018-05-30 01:47, Arne Vajhøj wrote:
> >> On 5/29/2018 7:41 PM, Simon Clubley wrote:
> >>> On 2018-05-29, Johnny Billquist <bqt at softjar.se> wrote:
> >>>> On 2018-05-29 01:16, Arne Vajhøj wrote:
> >>>>> On 5/28/2018 4:08 PM, Johnny Billquist wrote:
> >>>>>> Applications could be clever enough to actually refer to fields based
> >>>>>> on names, instead of just using fixed, known, chunks of the record.
> >>>>>> RMS do have names for the fields, which you can set and read.
> >>>>>
> >>>>> Both keys and values or only keys?
> >>>>>
> >>>>> I suspect key info is in XABKEY, but where do you find value info?
> >>>>
> >>>> What do you mean by value info? The values are in the individual 
> >>>> records
> >>>> obviously. And the key info will tell you which bytes in the record 
> >>>> that
> >>>> contains the value. Or are you talking about the type of the value?
> >>>> Which also also stored with they key info.
> >>>>
> >>>> Not entirely sure what you are thinking of....
> >>>>
> >>>
> >>> _If_ I understand Arne correctly, he is asking the following:
> >>>
> >>> Consider a C struct which is mapped to a RMS record:
> >>>
> >>> struct record_type
> >>>     {
> >>>     unsigned char primary_key[10];    /* This is the ISAM primary key */
> >>>     unsigned char value1[5];    /* Data value 1 */
> >>>     unsigned char value2[7];    /* Data value 2 */
> >>>     unsigned char value3[10];    /* Data value 3 and an alternate key */
> >>>     };
> >>>
> >>> You can find "primary_key" and "value3" in the key information.
> >>>
> >>> Where is value1 and value2 described in the RMS data structures ?
> >>> value1 and value2 are data fields only and do not have keys on them.
> >>>
> >>> IOW, what happens if value1 is extended from 5 bytes to 8 bytes ?
> >>>
> >>> This moves the start position of value2 to the right by 3 bytes.
> >>>
> >>> What field(s) in the RMS data structures can the application look
> >>> at to find the new offset to the start of value2 ?
> >>
> >> Yes.
> > 
> > Got it now. Yes, that information will not be in there. You need to have 
> > all your fields defined as keys in order to have the information there.
> 
> Or use CDD.

Thank you.

I was beginning to think that data dictionaries (such as DEC's 
CDD) had been a multi-year figment of various people's imagination
across the industry.

There was even a CDD<>ADA translator, for those who might think 
that making sure that the application's view of the data matched 
the database's view of the data might be a feature rather than a 
restriction. Times (and fashions) change. 

Some time after CDD arrived came DSRI (the DEC Standard Relational
Interface, from the 1980s) which probably did thirty years ago a 
lot of what is being talked about and asked for here in terms of 
record definitions and such. Grossly oversimplified: the client 
application sees the same well-defined API regardless of what the 
underlying DSRI-compliant database engine uses (and the database 
engine doesn't care about the details of its client application(s)).


If anyone wants to read more about this DSRI thing, search for 
"Jim Starkey" as well as DSRI and you'll find more. Or just search
for "Jim Starkey" and see where it leads.