Ok VMS was mentioned so I'll bite. BTW, I first used unix on
an 11, have used VMS since v1 or 2 .something.

VMS has many `config' files that are not either plain text,
or flat files. How ever, the `not flat file' part is not
such a big deal.

Since I don't know how well many readers know VMS, I best fill
in some background details about devices, file RMS etc... so
please be patient  ;)

The big difference, is that VMS, like RSX before it has a much
closer mapping to the hardware than unix. There is NOT the single
name space encompasing all files and devices, as in unix, nor
does it follow the `all the world's a file of a stream of bytes'.
I does however, have semantics that make device independence
reasonanly easy. IE opening a ( for instance ) paper tape
with a full directory spec and file name will return the
same status as a `real' file on disk. 

VMS also requires that disks in particular have certain garenteed
properties. 512 byte blocks, addressable to and block boundrary
for the beginning and a xfer, and xfer lengths mod 4. The last
is historical, almost. Also, the raw disk is quite visable to the
user! In fact, it is easy for a user to use an un-owned, unmounted
device with no FS at all.

On top of disks, is the ODS-2 file strructure. This defines how
a disk is structured into files. reserves certain files for
system use, for the file-system, and block 0 for the boot block.
Directorys are `just files' in theory, but a pretty usefull one ;)
in practise. How ever, You can, and often do bypass directories
on files the are opened and closed frequently. It is quite legal
to stash away and remember a `file-id' ( sort of like an i-node
number, but there are NOT unique system wide, but are on a device. ),
so gratuous changes are not a good idea.

The other difference here is defaults. VMS has no `default directory'
concept. Instead, it has a default device name and directory name.
Defaults on VMS work by substituting the default text strings
to form a full file name. You are never `somewhere' in the file
name space as in unix. To see what I mean by the latter, mount a floppy,
cd to its root, then try to dismount it. Or cd to /nonexistant...
On VMS, `set def [nonexistant]' is no problem until you USE it.

Third, on top of all that we dump everyones beloved RMS.
(flame on) VMS is brain dead in 2 areas with RMS. First
is a stupid limit of 32256 byte per record. This is because
the record size word is defined to be a signed 16b word. FCS,
on RSX had it as an unsigned 16b word. A value of 0 is an
empty record, a value of 177777(8) is a flag that says
`no more records in this block, go to the next one'. They
repeated that error with the version number as well btw...

The other screw up, is that VMS started pretending that
unstructed files, record type UNDEFINED, where now in
fact 512b FIXED records

Yes, records. a `line' is not alwatys delimited by an in
stream byte, but MAY be. In fact, a CR, a LF, or a CR-LF
can be the end of record (line) marker. Also, a CR or LF
delimiter says NOTHING about what is printed/displayed.
It ONLY says `end of record'. If the records are
implied cariage control, the a CR is prepended to the
record, and a LF appended, IFF it is transfered to a
`cariage-control' devise. Ie a printer, terminal...

But not only can records be aranged in a head to tail
sequential file, the file ca also be structured as a
`relative' fiel, or as an indexed file. These last ones
can be accessed by key, ie they are an ISAM file. Also,
the data areas of an indexed file are chained together
in order of primary key value. So sequential gets return
the data just as if it was accessed by ascending value
of primary key, but the key structures are not needed
at all. In fact, this is how you can recover a screwed
indexed file :( Yes, it does happen...

The principle example in VMS is SYSUAF.DAT. This is an
indexed file. But, because the record and index support
is in libraries, and application can just do a,...

open,
get,
get,
get,
...
close
 sequence just as if it was a flat file. The fact that it contains
non-printables many cause some fun however. So all the basic system
file tools work on it. If you have Datatrieve, a report generation
language, you can use that to manage them, up date them etc... This
IS a big deal if you have a weekend to dump last years student
accounts, and get this years in place. With 30,000 students. Plus,
come monday morning when they all log in and have to re-set their
password, only a single record is locked at a time, and you don't
have to search the file for the user!

Ther eis also a special program for frobing sysuaf, called authorize,
but it is  not esential. It's not much fun with out it, but you
can survive.

If you have a demanding site, you can use journaling on the sysuaf
so you can roll it back, or roll it forward from the last backup.
However, as ever login or batch or network login updates the last login
times, the journal files will grow pretty fast on a busy system.

The networking stuff also uses quite a few files that are `special'
formalt. Often in fact they are dumped data global sections that
are read by remapping. Recreation is simple, the program that
uses them is fed a text file to recreate them. In the case of the
network name-address file, it's even easier `ncp copy known nodes
from foo to perm' ` ncp set know nodes all' Oh, you do need
to remember the address of foo ;)

For system startup, it is most all text files of DCL eqv shell
scripts. Help files are standard library format. The librarian
can manipulate them and programs can use the callable librarian
library routine to access them. Or any other stuff bundled into
a library! Again, it's all basic `standard' stuff.

A real example. I keep my mail files at home on my vax. Every
month I backup the mail directory and copy it to home. I then
delete most of the old mail files and messages. Oh mail stores
small ( <2k ) messages in the main isam file mail.mai, and
large messages in seperate text files witha pointer from
mail.mai. So I backup the lot, xfer it, rename all the individual
files from the xfer directory to the main mail directory, leaving
any duplicates behind, then do a convert/merge on my home
mail.mai to add the new mail records. Again, all in the base
system, and I can still recieve mail as I'm doing it 8)

Now, yes, there probably are better indexed file systems than
RMS, and better disk structures than ODS-2, but because RMS
is `just there' everything uses it, rather than 69 different
b-tree/oo-db/... systems, none of which can interwork!

There have been exceptions to this. ACMS had it's
appication libraies. It also used TDMS, and it had its own libraries
as well. Both where LESS functional than either VMS or RSX's libraries
and each had its own special library tool... It was hated by all And,
no suprise, they where buggy. NIH rides again, even in VMS land.

Refering back to the NT registery... The problem there is not
that it is still buggy, time will possibly fix that. A bigger
problem is that it has no defined semantics. Some things
are bound at excecution time, some at system startup, some are
bound when they are defined... THAT is the real cluster-fuck
in that one.

~Paul
e&oe