|
Software > OpenVMS Systems > Ask the Wizard HP OpenVMS Systemsask the wizard |
|
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.
|