From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,39579ad87542da0e X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.224.217.195 with SMTP id hn3mr23957317qab.5.1368645514803; Wed, 15 May 2013 12:18:34 -0700 (PDT) X-Received: by 10.49.121.9 with SMTP id lg9mr1545817qeb.39.1368645514780; Wed, 15 May 2013 12:18:34 -0700 (PDT) Path: y6ni43806qax.0!nntp.google.com!m7no7898788qam.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 15 May 2013 12:18:34 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=129.59.203.69; posting-account=7Oy7OQoAAABhVYFOo553Cn1-AaU-bSfl NNTP-Posting-Host: 129.59.203.69 References: <12gn9wvv1gwfk.10ikfju4rzmnj.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Seeking for papers about tagged types vs access to subprograms From: Eryndlia Mavourneen Injection-Date: Wed, 15 May 2013 19:18:34 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2013-05-15T12:18:34-07:00 List-Id: On Wednesday, May 15, 2013 1:15:07 PM UTC-5, Jeffrey Carter wrote: >=20 > Physically, a disk is a bunch of bytes; everything else is built on top o= f that.=20 >=20 > The Unix file concept provides the building blocks but no higher-level=20 > abstractions. VMS (which, IIRC, did not initially have a sequence-of-byte= s way=20 > to access files) represented the other extreme. Presumably there are some= common=20 > higher-level file types that it would be useful to have the OS provide in= =20 > addition to the sequence-of-bytes view, just as it's useful to have a lan= guage=20 > provide common higher-level constructs as well as the building blocks to = build them. >=20 Actually, VMS and its predecessor RSX-11 (all flavors) provided a wide rang= e of choices from=20 1) physical block/sector device I/O to=20 2) logical block/sector file I/O to=20 3) variable-sized file record structure (sequential I/O) [the size was sepa= rate from the record but did not preclude the inclusion of terminator(s) or= any other characters in the record] to=20 4) fixed-length file record structure (sequential or direct I/O) to=20 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 t= hat is needed. I have seen many personnel REQs for DB programmer or admini= strator 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 mor= e 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 par= agraph(s) that dealt with the situation. Very helpful.] Eryndlia Mavourneen