Why use U* over VMS

Olli-Matti Penttinen pena at fuug.fi
Fri Nov 2 02:48:30 AEST 1990


In article <3749 at idunno.Princeton.EDU> rhl at astro.Princeton.EDU (Robert Lupton (the Good)) writes:

   >Before you all move over to VMS, happy in the knowledge that it supports
   >stream linefeed (unix-style) files, beware that the C rtl implementation
   >of read/write/open/close that works with them is glacially slow. Too slow
   >to be used (at least for the sort of image processing that I was doing).

  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.

  The worst thing is that (at least under VMS 4.x) you really had to
know the exact file type of a *TEXT FILE* to be able to do anything
usefull with it.  For example: you could not fseek into the middle of
a line (i.e. record) of a variable-lenght-record file, or
whatchamacallit, which happens to be the default for all FORTRAN and
EDIT output.  You had to convert it to stream type before processing.

  One other point: when was the last you looked at the source of
MicroEmacs?  I'm not saying that it's optimally (or even sensibly)
coded for each OS, but it sure strikes odd to find all that VMS only
code in it.

    MicroEmacs 3.10:
      ibmpc.c: 11928 bytes
      os2.c:   11389 bytes
      unix.c:  14470 bytes
      vms.c:   32526 bytes

Unfortunately (for VMS), there even are missing features ...

==pena
--
Olli-Matti Penttinen <pena at fuug.innopoli.fi>
Brainware Oy                      "When in doubt, use brute force."
Tekniikantie 17                      --Ken Thompson
02150  ESPOO, Finland   Tel. +358 0 4375 320   Fax. +358 0 4553 117



More information about the Comp.unix.programmer mailing list