Record-access libraries (Was: Re: VMS vs. UNIX file system)

[Richard A. O'Keefe]

In article <5722 at killer.DALLAS.TX.US> fmayhar at killer.Dallas.TX.US
(Frank Mayhar), writing about records, says:
>(2) if you provide the
>capability in a library (and you're not AT&T) applications that use it become
>non-portable, and (3) providing it in a library is not as efficient as providing
>it as part of the operating system, and if you do that what you end up with is
>no longer Un*x, as such.  One of the things that I hate most about Un*x is that
>it locks you into one way of looking at data:  as a stream of bytes.

Whether a particular vendor-supplied function is implemented in the kernel
or in a separate library is the vendor's business.  For example, DEC's "RMS"
facilities are *not* part of the operating system, but are a separate library.
Presumably DEC didn't agree that this was intrinsically inefficient.

Things in UNIX(tm) which were formerly system calls (such as sleep(2)) have
moved out to libraries, and things which were formerly library calls
(such as readdir(3)) have moved into the kernel.  If the ndbm(3) routines
were moved into the kernel, no application program would notice, and the
result would still be UNIX(tm).

Having things in a library NOT supplied by the O/S vendor should make
applications that use it *more* portable than having it as part of the
kernel.  For example, ndbm(3) is not provided by all UNIX(tm) vendors.
But if I buy source code for one of the B-tree packages which abound,
and I want to move my application, I just move the library with it!

UNIX(tm) doesn't lock you into one way of looking at data.
If you want IBM-style records (F, V, FS, ...), it's dead simple to build
on top of block-at-a-time access.  Several of the indexing packages made
for the PC market run under UNIX.  Ok, so you don't get VSAM, but is that
so bad?