Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site amdahl.UUCP
Path: utzoo!utcs!lsuc!pesnta!amdcad!amdahl!mat
From: mat@amdahl.UUCP (Mike Taylor)
Newsgroups: net.arch
Subject: Re: Magic Cookies and File Systems (Religious FLAME)
Message-ID: <1261@amdahl.UUCP>
Date: Mon, 11-Mar-85 12:11:44 EST
Article-I.D.: amdahl.1261
Posted: Mon Mar 11 12:11:44 1985
Date-Received: Mon, 11-Mar-85 22:24:38 EST
References: <917@sjuvax.UUCP> <538@rlgvax.UUCP> <190@u1100s.UUCP> <1078@watdcsu.UUCP>
Organization: Amdahl Corp, Sunnyvale CA
Lines: 20

> for those of you who don't know, OS/360 (really MVS) has both internal
> named locks (ENQ/DEQ) and file locks.  in a multiple processor
> environment without shared memory, file locks are used because there is
> really no other way.  the controller has the smarts to acknowledge a
> RESERVE and prevent all I/O from any other CPU's to that device until
> the CPU issuing the RESERVE is finished with it.

It's a small point, but the facts might as well be straight.
Since RESERVE/RELEASE locks an entire volume, not a file, resulting in
unwanted side-effects such as deadlocks, the internal named locks
may be propagated through all sharing processors by a facility
called Global Resource Serialization (GRS).
GRS uses channel-to-channel connection to pass a token around all
connected processors. Possession of the token allows tasks (processes)
on that system to obtain/release global locks. The token is passed every
n milliseconds (n = tunable parameter).
-- 
Mike Taylor                        ...!{ihnp4,hplabs,amd,sun}!amdahl!mat

[ This may not reflect my opinion, let alone anyone else's.  ]