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