From: dafuller@sequent.com (David Fuller)
Subject: Re: Multi uP P5 systems
Organization: Sequent Computer Systems Inc.
Date: Wed, 7 Oct 92 03:36:37 GMT

In article <1992Oct6.145437.792@infodev.cam.ac.uk> rf@cl.cam.ac.uk (Robin Fairbairns) writes:
>
>In article <1992Oct6.133255.2382@crd.ge.com>, davidsen@ariel.crd.GE.COM
>(william E Davidsen) writes:
>|> [of VMS]
>|>   I sure hope so. Any o/s which puts file types in the o/s instead of
>|> the program is really creating problems for the user, and I find that
>|> more of a problem than the user interface. If programs really want a "$
>|> delimited left handed nybble swapped hexadecimal" file type, let it be
>|> done in the program or shared library, and not at a level when all
>|> user-written file transfer and backup programs have to deal with it. As
>|> my youngest says "yucky-poo!"

Huh?  Let's think about this.

Tighter integration of file types to the OS are not a problem.  In my
experience, UNIX offers the weakest file maintenance offerings in the
industry, save for MS-DOS.  In using Tandem Guardian and VMS I've found
that ultimately, one could:

* Back up files.

* Transfer files.

* Convert files.

...much more easily and safely than with UNIX.  Yes, it was between 
Guardian or VMS systems but instead of going into an "open systems" (whatever
THOSE are) snit, read on.

As a result:

* Each RDBMS has its own backup and restore facility of varying 
  functionality, quality, and effectiveness, complicating support for
  sites adopting more than one RDBMS.  

* All existing UNIX backup and restore facilities are highly 
  dysfunctional compared to similar facilities under the aforementioned 
  operating systems.  They can make only the grossest assumptions about 
  file contents (back it up or not, bud?) and thus cause vast redundancy 
  in backups; if you change a single byte in the file, you back up the 
  whole thing instead of changed records.

* Transferring files from system to system under UNIX requires that
  all layers of functionality be present on both sides to interpret
  files of arbitrary form and content.  Embedded file systems 
  ensure that file transfer is enhanced because the interpretation 
  and manipulation facilities will be there even if the highest
  layers aren't (ie: you can at least decompose the file).  Find 
  me one person who guarantees they can decompose an Oracle or Ingres
  file (ie: someone who has a product that will always do it and 
  guarantees it'll work for all successive releases of these packages).

Once one strips away the cryptology, the issue is control.  UNIX is
an operating system that offers the promise of ultimate user control
(ie: no OS engineer's going to take <feature> away from ME!), which was
a good thing in its infancy, less good now, where the idiom has caused
huge redundancies between software packages.  How many B*Tree packages
do we NEED?  I think that I learned factoring in high school; and that
certain file idioms are agreed to in the industry as Good Ideas.  So
why not support certain common denominators in the OS?

Just because you CAN do something in user programs does not mean it's 
a terribly good idea to enforce it as policy.  If society ran the same
way UNIX does, everyone who owned a car would be forced to refine their
own gasoline from barrels of crude...  

-- 
Dave Fuller		 	All opinions expressed are my own and not
Sequent Computer Systems	those of Sequent Computer Systems, Inc.
dafuller@sequent.com