Xref: utzoo comp.unix.programmer:461 alt.religion.computers:2032 Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!noao!ncar!zaphod.mps.ohio-state.edu!samsung!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.unix.programmer,alt.religion.computers Subject: Re: Why use U* over VMS Message-ID: <4312@auspex.auspex.com> Date: 10 Nov 90 02:20:10 GMT References: <1990Oct31.141954.22736@druid.uucp> <3749@idunno.Princeton.EDU> Followup-To: alt.religion.computers Organization: Auspex Systems, Santa Clara Lines: 25 (Dunno if "alt.religion.computers" is the right place, but it's probably better than "comp.unix.programmer" at this point....) > The best thing about RMS is it's ability to support DBMS's which >generally run circles 'round a similar one under Ultrix/BSD. Besides, >it's a little bit simpler to implement a database using a filesystem >w/ built in ISAM instead of opening a Unix partition and seeking here >and there. Does a UNIX system with, say, an XPG3-compliant ISAM library have "a filesystem w/ built in ISAM"? If not, why not? If the answer is "because that's implemented atop the file system rather than built into the file system", how is this different from VMS, which as I remember implements ISAM, just as it implements the various text file types, atop QIOs that just read and write blocks of files? If the answer is "well, RMS runs in *executive* mode rather than *user* mode", how much does this really matter? If the answer is "well, Files-11 lets you store all sorts of attributes in the file header that the low-level QIO interface doesn't interpret, but that RMS does", again, how much does this really matter?