Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 2/19/85; site seismo.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!gatech!seismo!mo
From: mo@seismo.UUCP (Mike O'Dell)
Newsgroups: net.arch
Subject: OS Locking and Paged file systems
Message-ID: <1683@seismo.UUCP>
Date: Wed, 13-Mar-85 08:47:41 EST
Article-I.D.: seismo.1683
Posted: Wed Mar 13 08:47:41 1985
Date-Received: Thu, 14-Mar-85 05:45:36 EST
Organization: Center for Seismic Studies, Arlington, VA
Lines: 32

(1) OS/MVS file locking is done using the internal name lock mechanism.
The qname is 8 chars and the rname is 256, with several reserved
qnames, like SYSDSN.  In older systems (SVS, MVT, MFT), none of the
qnames were reserved (limited to authorized code) leading to
cute ways of wedging systems by writing short asm programs which
locked SYS1.LINKLIB even if they were password protected.
There were even more interesting things you could do because the
ENQ call copies the qname and rname into protected storage, and the
rname was large enough to contain data structures (like DEB's) and was
not checked to be anything in particular.

(2) One oft-overlooked problem with memory-mapped files is that 
the notion of END OF FILE becomes imprecise at best and non-existant
at worst.  This is because pages don't have 1 byte granularity, or
even 1 record granularity, unless your records happen to be PAGESIZE.
If the file buffering stuff maps things in only for its buffer management
purposes, it could do something after the open to find the actual file
size recorded in the filesystem and then provide EOF signalling to the
client, but this means the I/O library has to know about such matters.
This seems awfully sloppy at best.  The filesystem should implement files,
not do a half-way job that must be papered-over to work like people expect.

Part of the problem, of course, is that Multics never offered to provide
files - it provides segments; they even changed the name to reflect
the subtly-different semantics.  This was not done just to complicate
the documentation.  So before you generalize files away, make sure
you don't generalize away some semantics which are very useful, not to
mention widely-expected by programs written on an operating system
more sophisticated than CP/M (this is not a comment on Multics - remember
Multics doesn't offer files, but CP/M professes to).

	-Mike O'Dell