mo@seismo.UUCP (Mike O'Dell) (03/13/85)
(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