Re: Seeking for papers about tagged types vs access to subprograms

[Eryndlia Mavourneen <eryndlia@gmail.com>]

On Wednesday, May 15, 2013 1:15:07 PM UTC-5, Jeffrey Carter wrote:
> 
> Physically, a disk is a bunch of bytes; everything else is built on top of that. 
> 
> The Unix file concept provides the building blocks but no higher-level 
> abstractions. VMS (which, IIRC, did not initially have a sequence-of-bytes way 
> to access files) represented the other extreme. Presumably there are some common 
> higher-level file types that it would be useful to have the OS provide in 
> addition to the sequence-of-bytes view, just as it's useful to have a language 
> provide common higher-level constructs as well as the building blocks to build them.
> 

Actually, VMS and its predecessor RSX-11 (all flavors) provided a wide range of choices from 

1) physical block/sector device I/O to 

2) logical block/sector file I/O to 

3) variable-sized file record structure (sequential I/O) [the size was separate from the record but did not preclude the inclusion of terminator(s) or any other characters in the record] to 

4) fixed-length file record structure (sequential or direct I/O) to 

5) indexed-sequential file structure (sequential or indexed I/O using 1 or more indices).

RMS (Record Management Services) represented the last 3 (3-5) of these.
These choices are so complete that for many DB applications, they are all that is needed.  I have seen many personnel REQs for DB programmer or administrator that specified the DB as RMS.  I have used all 5 I/O modes and did not find any of them particularly difficult or cumbersome to use.  Even more so with Ada.

DEC's layered product Rdb provided for true relational DB capability.

Btw, VMS is still maintained and upgraded by HP.

[As an addendum -- I used DEC Ada and preferred it in some ways over Gnat.  Error messages are the main thing that comes to mind.  DEC Ada didn't just give you the error message but cross-referenced it to the specific LRM paragraph(s) that dealt with the situation.  Very helpful.]

Eryndlia Mavourneen