 |
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.
|
|
|
|
|
