Process must continue after client disconnects

[Douglas Fisher]

I have an app that needs to continue processing after the client has disconnected.
The client runs on a pc and connects via telenet.
We'er running vms 8.2.

I've looked through the doc's and have not found anything.

Does anyone have a suggestion?

[Jim_McKinney]

If the goal is to permit the user to reconnect then consider virtual terminals - specifically check out the SYSGEN parameter TTY_DEFCHAR2 - specifically bit 17 (20000(hex)). After setting that bit you may need to alter the config of your telnet server - how to do so depends upon your IP stack. A google search for "virtual terminals telnet" and your IP stack should yield the proper instructions.

[Volker Halle]

Douglas,

note that the app should not do any read/writes to the terminal once the TELNET session has been disconnected, as those IOs will be blocked until a session is re-connected to the virtual terminal.

Also note that OpenVMS will stop the process, if the virtual terminal is still disconnected after TTY_TIMEOUT seconds (SYSGEN parameter).

Volker.

[John Gillings]

On an OpenVMS Alpha or IA64 system, to enable virtual terminals you need to:

1) Set the DISCONNECT bit in TTY_DEFCHAR2 (add %X20000)

2) load the virtual terminal driver during startup:
$ MCR SYSMAN IO CONNECT VTA0/NOADAPTER-
/DRIVER=SYS$LOADABLE_IMAGES:SYS$TTDRIVER.EXE

3) For TCPIP devices, define the appropriate logical name(s):

$ DEFINE/SYSTEM/EXEC TCPIP$TELNET_VTA TRUE
$ DEFINE/SYSTEM/EXEC TCPIP$RLOGIN_VTA TRUE


TTY_TIMEOUT can be set to arbitrarily large values to increase the time before a disconnected process will be kiled. I have a system where it's set to approximately 3 months - no problem for me, but might be a problem with large numbers of users. The maximum possible value is about 68 years.

Obviously the process will block on any input request from the terminal. Depending on your connection, the process may or may not be blocked by output to the terminal. There may be (very limited) buffering.

If there's a specific task that needs to be started, maybe it would be best to redirect output?

$ @DISCONNECTED_TASK/OUTPUT=DISC.LOG

Or, maybe consider submitting it as a batch job?

$ SUBMIT DISCONNECTED_TASK

[John Gillings]

Douglas,

re: output buffering...

If you can't control the output from the processing you want to continue, it looks like this might help.

Simple experiment, write a command procedure with a counting loop. Write the count to the terminal, and also to a log file (open and close each iteration so progress can easily be checked from another process). Connect to the node, start the procedure, then disconnect. The disconnected process will block on the first attempt at output.

Now, connect to the node, then immediately telnet to the same host:

telnet vmshost
Username: self
Password:
$ telnet 0
Username: self
Password:
...

Start the procedure and disconnect (which will disconnect from the "outer" telnet session). Output from the "inner" session is now buffered somewhere. No idea where or what it's limited by. Looks like it eventually blocks on an output request.

[Douglas Fisher]

Thanks to everyone who answered.

The app is an ancient one and had some issues that once we looked into them it was decided to use llc2 as a transport for x25 instead of converting it.

Thanks again I learned a lot from the replies.