HP OpenVMS Systems

Distributed process control?

» close window

The Question is:

 
Years ago I wrote a detached process that logged process logins and logouts to
 a printer.  This detached process would create some of these processes, in
 which case it would set the process termination mailbox unit to a mailbox it
 monitored.
 
Other processes were able to "register" with this detached process, such that
 upon registering the client process would be "logged in" and the tmbu portion
 of the PCB set to the appropriate termination mailbox unit.  This was written
 for VAX and used a sp
ecial kernel mode AST to do the work.  This still works to this day.
 
My question is what would be the best replacement for this mechanism using
 supported constructs that would work on both VAX and Alpha?  Again, some
 processes are created using $creprc by this detached process, others are not
 under the control of this deta
ched process, but upon registering, still must elicit a "log out" message on
 the printer when that event occurs.
 
Ideally I would like to keep the termination mailbox concept going as the
 mechanism would be the same in both cases - keep a read going on the
 termination mailbox, when a message is received analyze the process
 termination message and log the appropriate
message.  If that isn't an option, then I guess I could use the Audit Server,
 however this would be require system configuration changes on a number of
 systems.  TIA.
 
 

The Answer is :

 
  Assuming that the various available third-party process management and
  process control software is insufficient, the use of the distributed
  lock manager would be the approach used by (and recommended by) the
  OpenVMS Wizard.
 
  Use the lock value block is available for (controlled) messages from
  the client back to the server on exit, with values set either via
  in-line code or via the code of a condition handler or exit handler.
 
  When registering, the process would request acceptance via a message
  sent to the controlling process (via DNS lookup, known lock name,
  etc), and this request would include sufficient information to create
  a lock resource name unique to the requesting process (possibly with
  the resource name further characterized by the particular "group" of
  processes and also by the particular application).  The process will
  have already queued an exclusive lock on the resource.  If the request
  is granted (and the process admitted to the group), then the managing
  process queues an incompatible lock on the same resource, specifying
  a granting AST.  If the granting AST is triggered, then the client
  process has exited.
 
  This scheme can be extended out to other nodes within an OpenVMS
  Cluster, of course.  Multiple managing processes in an OpenVMS
  Cluster can also be in operation, with only one of these processes
  holding the lock that indicates it is the master.
 

  

     

     
answer written or last revised on ( 31-JUL-2000 )
     
» close window