10-21-2013 09:59 AM
We use Esker's Smarterm app to emulate VT420 terminals on our Open/VMS Ingerity system. I'll admit that we do have training issue here, however when our staff disconnect from VMS by clicking the "X" on the terminal emulation app, without logging off VMS first, we get runaway processes that chew up a very high percentage of our CPU.
We have devised a script to kill these runaway processes,but we would prefer not to get them in the first place.
Would appreciate any insights into what might be causing this and what we might do to prevent this from happening.
We are also working with Esker to try to add a script that send a logoff command when the app is closed.
10-21-2013 10:15 AM
what images are running in these 'looping' processes ? Use SHOW PROC/CONT/ID=<pid> against some of those.
What typically happens, is that an image is sitting on a prompt, reading from the terminal. If the TELNET session gets terminated, there could very well be an IO error reading from the terminal. And the application might just re-try in case of an IO error when reading from the terminal. As fas as I remember, All-in-1 was some of those applications, which kept re-trying on failed terminal reads...
10-21-2013 10:50 AM
Just to follow up on what Volker said, it's likely not the terminal emulator but the application the user is running, which may well have an exit handler that tries really hard to get confirmation from the user that they want to exit. Such an exit handler really ought to confirm the terminal is still there, probably by calling $GETJPI with DVI$_AVL.
When I saw this problem it was in a discontinued third-party app with no prospect of getting the exit handler fixed. So I wrote a program that periodically scanned all the interactive processes on the system and killed any with the terminal in an offline status. Kind of a big hammer but it worked.
10-21-2013 08:17 PM
Maybe I should have explained teh reason for my question... Years ago I had a client with a big problem that had been there for months. It was running a pay-TV application on VMS being accessed from PCs. Every time the PC session was terminated - either just the session or the PC switched off - the VMS system would go to 100% CPU for about 10 minutes.
The reason was simple. The exit handler in the pay-TV software wasn't working correctly and the database beneath it was rolling back after any abnormal termination of a connected VMS process. After the pay-TV software was corrected the problem disappeared.
10-22-2013 03:45 AM
Using the SDA MAP command with the values obtained with a working process utilizing the same softare should provide clues.
Contact me directly if you need more assistance.
11-06-2013 06:25 AM
Dan - Thanks for the info.
The tools you reference are not known to me, but I mucked about in VMS help and I think I was able to generate some data.
I will take you up on your office for assistance via private email.
11-13-2013 12:23 PM
We also use SmarTerm and we get these runaway processes once in a while. It happens whenever the user X's out of SmarTerm without logging off. I looked into this deeply back in 2007. At first I looked at tcp/ip, and eventually came to the conclusion that somehow it was FMS that was the culprit. Do you use FMS? Anyway, the bottom line is we ended up writing a DCL program that monitors the system and automatically kills these runaway processes since we couldn't get FMS fixed.
11-14-2013 04:49 AM
A solution is usually easy. It is the tracing of the exact problem that is tricky.