Path: utzoo!mnetor!uunet!husc6!mit-eddie!minya!jc
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.unix.wizards
Subject: Re: VMS, UNIX, etc.
Message-ID: <487@minya.UUCP>
Date: 21 Mar 88 02:26:07 GMT
References: <397@lscvax.UUCP> <20596@bu-cs.BU.EDU>
Organization: home
Lines: 84
Summary: Some CMS failings...

In article <20596@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes:
> Kilroy extols the virtues of VM/CMS over Unix or VMS...
> 
> To share files across user mini-disks you need the READ and/or WRITE
> password to the disk. There's no per-file permissions, either you give
> away everything or nothing. Not an ideal situation from a security
> point of view.

You missed pointing some major problems with shared CMS mini-disks.
Each user's CMS caches the directories of all attached mini-disks.
This means that if you attach my disk, and I re-compile a program,
you will for some time continue to get the old copy.  I once saw
a case where a friend asked when I was going to correct a bug he
had reported; I was surprised because I'd done so a week earlier.
But he had remained logged in for the entire week, and his CMS was
still using the old copy.

This isn't nearly as much fun what happens to you when my changes 
reach the point that a disk compaction occurs.  Your in-memory copy 
of my directory is now totally bogus.  The result is often a crash 
of your CMS (which at least has the effect of forcing you to login 
all over, thus refreshing your copy of my directory :-).

There's another gotcha that bit me on several occasions.  CMS has
knowledge of record formatting of files, and you must declare the
format (record size, and whether it's fixed or variable) when you
create a file.  There is a 'feature' of CMS that causes the attributes
of a file to be ignored if there is already a file with the same
name in ANY attached mini-disk.  Instead of your chosen attributes,
those of the existing file are used.  For an example, suppose you
ask to create a file with 136-byte records, but there is already
an identically-named file in a system library with 132-byte records.
You won't get any error; your records will just be silently truncated
to 132 bytes.

Furthermore, there is a 'feature' that causes a seek followed by a
write to a variable-record-length file to silently discard the rest 
of the file.  Every record written is followed by an EOF.  Suppose 
you create a fixed-record-length file (in which random seeks and 
writes work properly), but there is a variable-record-length file 
with the same name in a system library.  Your file will be silently 
created as variable-record-length.  Seeks and writes will appear 
to work, but file truncation will occur after every such write.

The solution is to write a creation routine that generates names until 
it finds one that doesn't exist in any attached mini-disk, creates the 
file with that name, and renames it to the desired name.  IBM people
will suggest this with a straight face, as if it were a reasonable
way to use the programmer's and the computer's time.

Another good 'feature':  If you create, say, a variable-record-length
file of 200-byte (max) records, you can then write records of any
length from 1 to 200 bytes.  When the creating program closes the
file, the close routine replaces the record length with the length
of the longest actual record.  Suppose that was 140 bytes.  If you
then run a program that seeks to the EOF and tries to append a record
of 150 bytes, the record is silently truncated to 140 bytes.  The
solution to this one is to make sure that you pad at least one record
to the full 200 bytes.

This may be your idea of a well-designed system; it isn't mine.

BTW, note that IBM hasn't yet discovered the uses of the number zero.
You aren't allowed to create records of 0 bytes.  At least you get an 
error from that one, but it means occasional silly code to test for 
empty records, and append a space.  Not a big deal, perhaps, but it's 
one more gotcha to slow down your job and your program.

You also get an error if you create a file and try to close it before
writing any data.  If you exit anyway, the file won't exist.  A null
file is as illegal as a null record.  

Unix, of course, has its share of such sillinesses.  But compared to
CMS, it is a paragon of mathematical reasonableness.  Most trivial cases
actually work correctly.  On the other hand, recent releases have been
getting more clever about trying to prevent you from saying things like
"rm *", so given enough time, Unix will probably come closer to CMS in 
the gotcha competition.  Consider that csh disallows null commands, so 
you can't create an empty file any more by just saying ">foo", you need 
to type "echo>foo".  A future release will probably disallow echo without 
args.  Sigh.

-- 
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)