Operating System - OpenVMS

Re: process termination mailbox

Go to solution
Frequent Advisor

process termination mailbox



when creating a detached process it is possible to get informed via termination mailbox



is there a chance to get this information from an interactive process

connected via telnet to a terminal emulation software like putty?


we are running OpenVMS versions from 6.2 (VAX) to 8.4 (I64).





Steven Schweda
Honored Contributor

Re: process termination mailbox

> is there a chance to get this information from an interactive process
> connected via telnet to a terminal emulation software like putty?

   I know nothing, but, given that you're not starting the process
yourself, I don't see how you could create/find/use such a mailbox.

   As usual, it can be more helpful to describe the actual problem which
you're trying to solve, rather than asking how to implement some
particular "solution" to that problem.

Frequent Advisor

Re: process termination mailbox

hi steven,


the problem is:


Users log in to our vms system using a terminal emulation like putty on a windows system.

They are using a captive account allowing to run only one application.


During startup of their application a background process is informed about the new process, creates an entry in a list

and distributes messages to the users using distributed locks.


When they have completed their work they should leave the application in a proper way which informs the background process of the leaving user, deletes their entry form the list and logs them out.


But instead of using this kind of "application rundown" some click on the "close window" button.

Sometimes the windows system crash and the result is the same.

The list of active application users is growing and growing.

Well, there is a cleanup procedure running on sundays but my goal is to keep the list as clean as possible everytime.



Steven Schweda
Honored Contributor

Re: process termination mailbox

> [...] run only one application.

   Not a very detailed description of "one application".

   If "application" dies when the user gets disconnected, then an exit
handler might be able to make things tidy, irregardful of why the
process exits.

   If you can't make that sort of change to "application", then perhaps
you could add a wrapper of some kind (perhaps the captive-account DCL
script itself?) to intercept and deal with the problem when it occurs.
Without any actual details, it's hard to suggest anything specific.

Respected Contributor

Re: process termination mailbox

As Steven has indicated., there are ways to handle this useing exist handlers if you have access to the sources.  If not, then there are ways to handle this via DCL command procedures.  If you'd rather not post details in this public forum, contact me directly and we can discuss your options.



Craig A Berry
Honored Contributor

Re: process termination mailbox

It is easy enough to find the termination mailbox (if it exists) and you can even read from it, but that read will be destructive and will steal the message from whomever it belongs to.  In other words, like Steven said, you really can't read from it unless you're the one who created it. 


It might be possible to post a write attention AST to the termination mailbox and simply be notified that it's been written to without reading from it, but only if it exists.  Given that the termination mailbox unit is zero on a telnet session created with TCP/IP services, I'd guess it doesn't exist:


$ write sys$output f$getjpi("","TMBU")


An exit handler is likely more workable, but be sure you don't try to get anything from the user whose terminal is disconnected.  That may seem obvious, but I saw an exit handler once that got itself stuck in a cpu-bound loop asking the user "Do you wish to save before exiting?" even though the user had already disconnected and was never going to see that message.



Honored Contributor

Re: process termination mailbox

Ah, what fun.  The joys of updating legacy application designs in modern networks...


This problem is quite similar to the problems folks are encountering when they try to extend an existing and usually an old application design —and particularly a design that assumes a reliable network — out into the modern mobile-client networking environment.  Where network connections can degrade and can fail at random.


I'm somewhat skeptical around designs using termination mailboxes and using image and process rundown handlers in general, as those handlers can't always be run; Windows crashes as you've mentioned, or during OpenVMS cluster member crashes, for instance. That means the application can be in an unexpected state.   Because of this, there are a number of VMS applications that don't recover very well after VMS crashes.  If at all.  Sometimes there's a cleanup or repair pass, and sometimes the cruft just builds up.  Sometimes there are latent corruptions secondary to incomplete changes.


First confirm that your application server back-end isn't already getting some sort of hangup request, and either ignoring it or mishandling it.  Sometimes there's an SS$_HANGUP that's getting ignored — this depends on details of your application environment not yet in evidence, unfortunately.


If you're looking to fix this in the application design, then the usual approach involves moving the user front-end client processing from the server out to the client boxes (either with a traditional fat client, or with an approach as an HTML5 web application — HTML5 is quite capable of booting Linux), and maintain the state on the server.   Sometimes with ZeroMQ or similar as the connection, if there's more application state than just the "here's a change, commit it or reject it" sort of updates.   Yes, it's sometimes possible to graft the front-end changes onto an existing application.  But in the more general overhaul, this can involve designing and implementing the application communications code as a state machine, if not the whole application.  This is usually a significant effort with an existing application, though.


If you're looking for a hack, then you're headed toward network keepalives and/or process polling from the background server, or toward a network connection to the foreground process that will fail when the process exits — a TCP socket, or a subprocess that's holding a lock that's coordinating with the server, etc.    Or a front-end application image that replaces that captive procedure.   VMS doesn't really have the concept of registering "interest" in an arbitrary process; the target processes have to explicitly be coded for that and must cooperate.   Or you poll.  VMS also lacks a distributed job manager and job scheduler, which can be a much more general solution to the problem that you're experiencing here.


As a different approach, it's sometimes possible to start a process from the server based on a session-initialization request received from the client, and back-connect the view to the client.  To reverse the current connection flow, secondary to some trigger from the Windows client.   This can be via an X session, and there are other (and sometimes variously ugly) ways to achieve this outward connection.  With this, you can get the termination mailbox.  (This is part way to a thin-client approach, too.)


The really ugly hack is to enable virtual terminal support for telnet, though — should everybody log into the same captive username — there can be issues that will preclude this approach.  (Having a shared login can also generally preclude user accountability, but that's fodder for another time and another discussion.)   When the session drops, the reconnection gets offered the old session, until that preserved session times out.   (This approach can get into trouble when the session is holding a lock that blocks something else, as can happen with RMS and occasionally with a database, or when timing out the "dangling" session leads to data inconsistencies.)


The massively ugly hack is a terminal timeout program; an idle-process killer; an idle session killer, in this case.  Either separate from the application, or application-integrated.  Brute-force polling, with no particular confirmation of the state of the user.  This can lead to data inconsistencies, when the process is terminated.  (Yes, it's possible to trigger exit handlers here with an application image front-end, but a captive command procedure doesn't really have the easiest time with implementing any form of exit handlers.)


The ultimately ugly hack: shut off the Microsoft Windows session-close button.  (More, more.)  That might mean rebuilding PuTTY, or other hackery.   This doesn't actually fix the problem, of course.

Mark Hurcombe

Re: process termination mailbox

As a possible option, maybe you can modify the "background process" that is notified when a user logs in to also keep track of the PID in the file you mention that stores the list of users.

When any user logs in and is added to the file, also scan the entire file and if any of the PIDs no longer exist, remove the associated entry.

You then have a more or less automatic cleanup mechanism and it doesn't rely on termination mailboxes etc.

You mention I think that you've got a broad range of operating system versions, so if you're also using clusters you'd need to make sure the cleanup mechanism will handle that. Maybe need to store the node name in your file as well.


John McL
Trusted Contributor

Re: process termination mailbox

An Exit Handler will catch most things but what you can also do if you store the PIDs is regularly scan the system to see if a SYS$GETJPI returns an error equivalent to "non-existent process" and that's the case take steps to remove any references from the system.  I'd poll every five seconds because a simple $GETJPI using PID isn't that resource-expensive.


You've not said whether you have access to the source code of the detached process.  I hope you do because either it can do the scanning (and receive other info via AST) or you can put the PIDs (and maybe other stuff) in a shared global section where the "job still alive?" scanner can access it and potentially any monitoring programs that you want to write.

Jess Goodman
Esteemed Contributor

Re: process termination mailbox


Since you have years of experience with VMS, I willl assume (unlike the other posters) that you have a need for the information contained in the accounting record that is written to a process termination mailbox. So I will answer your original question: Yes.

The attached file, SET_TMBU_KRNL.TXT, is actually a short macro-32 subroutine; rename it to .MAR of course. Use SYS$CMKRNL to call it from a program that is installed with CMKRL privilege and run it  from the captive command procedure.

 #include <starlet.h>
 extern int set_tmbu_krnl();

 int status;
 int arglist[2];

 arglist[0] = 1; /* One argument */
 arglist[1] = mbx_unit; /* the mailbox device unit number */
 status = sys$cmkrnl( set_tmbu_krnl, arglist);

This will work on VAX, Alpha, or IA64.

But if you don't need the accounting information then, since your appliation is already using distributed locks, the simplist solution might be to use a "dead-man" lock.  I can explailn this further if you need more details.

Jess Goodman

I have one, but it's personal.