From: hoffman@xdelta.zko.dec.nospam
Sent: Friday, December 10, 1999 2:55 PM
To: Info-VAX@Mvb.Saic.Com
Subject: Re: Do locks belong to processes or images?


In article <009E26A4.73395EF0@SendSpamHere.ORG>, system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) writes:
:In article <1999Dec10.135808.1@eisner>, snadow@eisner.decus.org (Scott Snadow) writes:
:>In article <82rba6$6e8$1@mailint03.im.hou.compaq.com>,
:>hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes:
:>>   Most locks are issued on a process basis, though you are getting
:>>   tangled up with image rundown (sys$rundwn) in this case -- when the 
:>>   image exits, locks (that are not system and not in a privileged mode) 
:>>   are released.

  That should more clearly read: 

    ...that are not system-owned and not in a privileged mode...
 
:>I _did_ try getting the lock with the LCK$M_SYSTEM flag, but this didn't
:>make any difference.  I am running with SYSLCK privilege, which the
:>manual says is required to use that flag.  I wonder, though, is the fact
:>that I'm at user mode when I get the system lock preventing the lock
:>from persisting beyond image rundown? 
:
:The LCK$M_SYSTEM flag only controls the interpretation of the resource
:name created.  Read Hoff's post more carefully.  The LCK$M_SYSTEM is
:used to make the resource name systemwide.  If you do not use the flag,
:the resource name is interpreted on a group basis.  


  The two flags are LCK$M_SYSTEM and the (don't use it) LCK$M_CVTSYS.
  The former is used when you need to cross UIC groups, the latter
  "moves" the lock from process ownership over to system ownership...
  (LCK$M_CVTSYS means you have to clean up after yourself in this case,
  which is not particularly more useful than a lock file or similar...)


:>Stupid Question Alert!  The manual tells me how to switch to executive
:>mode (SYS$CMEXEC) and kernel mode (SYS$CMKRNL) --- but not supervisor
:>mode.  How do I do that?

  Okfine, I'll stick a "Where's SYS$CMSUPER?" in the next FAQ...

:If you don't have or can't get (at a minimum) the CMEXEC privilege, you
:might consider another mechanism to solve your current problem.

  You can also use the sys$cmexec call, and then specify a less-privileged 
  acmode argument for the sys$enq[w] call...  (Beware: if you choose to 
  use the blocking or granting AST mechanisms of sys$enq while executing
  in executive mode, the ASTs would still be triggered in executive mode.
  The ASTs are not controlled by the acmode argument, in other words...)
  Using the acmode argument is arguably (no pun intended) slightly easier 
  than "unwinding" or ASTing out into to supervisor mode from executive...

 --------------------------- pure personal opinion ---------------------------
   Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com