Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!panda!talcott!harvard!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.arch
Subject: Re: RMS v/s UNIX (non-religious)
Message-ID: <538@rlgvax.UUCP>
Date: Fri, 1-Mar-85 18:29:38 EST
Article-I.D.: rlgvax.538
Posted: Fri Mar  1 18:29:38 1985
Date-Received: Mon, 4-Mar-85 07:45:16 EST
References: <917@sjuvax.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 20

> The problem lies in picking an underlying model sufficiently robust
> to do all of the things you want to do with record and file locking, ...

Well, several UNIX versions *do* have record and file locking - System V
Release 2 Version 2, for one.  They are based on John Bass' byte-stream
locking mechanism; you lock a given range of bytes in the file.

VMS, on the other hand, has a locking mechanism that locks magic cookies;
cooperating applications agree on a name for a resource and they lock
that name when they want to lock that resource.  This goes all the way
back to OS/360's ENQ/DEQ locking primitive, which locked names made of
an 8-character "qname" and an 8-character "rname" - queue and resource
names, probably, giving a two-level hierarchy.  I believe VMS supports
N-level name hierarchies, for N reasonably large.

This means you can lock things other than files; perhaps locking should
have nothing to do with the file system.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy